[server] Get rid of MembershipRowToDelete.forceRowCreation

Summary:
When we first introduced this, we didn't perform a full analysis to see if it mattered. After reading the code, I've concluded we can just always do an INSERT INTO ... ON DUPLICATE KEY and the behavior will be identical.

The reason is that we only ever add an operation: 'delete' to a membershipChangeset when a membership row already exists. That is certainly the case in recalculateThreadPermissions and updateDescendantPermissions, which explicitly check if the permissions blob has changed (so if a null permissions blob is written, we know it must've been non-null before).

changeRole is a bit more complicated, but it has only two callsites where role = 0. (Note that role = -1 is already handled with an INSERT INTO ... ON DUPLICATE KEY because of forceRowCreation, and role > 0 should not result in an operation: 'delete'.) Both callsites where role = 0 explicitly make sure to only pass in userIDs where a membership row already exists.

Test Plan: Careful analysis of code paths, Flow. This diff basically just removes a codepath... none of the code is new

Reviewers: palys-swm

Reviewed By: palys-swm

Subscribers: KatPo, Adrian, atul

Differential Revision: https://phabricator.ashoat.com/D1023