[server] Split MembershipRow.operation into three parameters

Summary:
The operation field is heavily overloaded right now. In particular, the difference between join and update is overloaded.

Currently, we always set update, except we set join in changeRole when the user previously had a non-positive role (ie. was not a member). We then consider update vs. join in four places:

1. We send updateTypes.JOIN_THREAD instead of updateTypes.UPDATE_THREAD for join. But this is not the correct way to think about it... the difference in these types has to do with whether we send extended info (eg. current calendar state, latest messages) down to the client, and those fetches will return things when the user has VISIBLE permissions.
2. We set the subscription to have push notifs on for join. Note that the SQL query only ever sets this when the role becomes positive or becomes non-positive. In this diff our change should be a no-op.
3. We decide which rows to prefer if there are multiple for a (user, thread) pair based on join vs. update. In this diff, we change it so that we always prefer a call from changeRole (eg. that has an intent set), since changeRole always has more information than recalculateThreadPermissions.
4. We only set last_message and last_read_message to represent an "unread" status for a join. This is okay to do more generally (for update as well) because considering them for an update doesn't change anything given that they aren't set in the case of ON DUPLICATE KEY.

Test Plan:
I tested all the ways that commitMembershipChangeset can get triggered:

• joinThread
• removeMembers
• updateThread
• createThread
• updateRole
• leaveThread

Reviewers: palys-swm

Reviewed By: palys-swm

Subscribers: KatPo, palys-swm, Adrian, atul

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