Refactor adminIds in UserList

[matthew-white]

Right now in UserList, the data property adminIds is a Set that contains the ids of users who are sitewide administrators. We keep the Set up-to-date, adding or removing an id after a user's role is changed. However, a Set is not reactive, which means that Vue will not automatically react to an addition or removal. I have confirmed this using Vue devtools:

• A UserRow is passed an admin prop based on whether the associated user's id is in the Set.
• If the user's role is changed, the admin prop does not change.

I think the reason why things work today is that UserRow has its own data property, selectedRole, that indicates the user's currently selected role. UserRow uses the admin prop to initialize selectedRole, but it does not react to changes to admin.

If adminIds is only used to initialize UserRow, then I think we should make that explicit in a comment and remove the code that tries to keep adminIds up-to-date — since Vue won't see those changes anyway.

Alternatively, we could change adminIds from a Set to a simple object so that Vue reacts to changes to it. We could then have UserRow only use the admin prop, removing the selectedRole data property. Maybe we could use v-model?

I think something similar is happening in ProjectUserList. After a user's role is changed, we update the roleId property of the associated element of projectAssignments. However, I think the roleId property is just used to initialize ProjectUserRow, which has its own selectedRoleId data property. There are some differences from UserList though. First, ProjectUserList does not use a Set, so Vue will react to the change. Second, although an existing ProjectUserRow will not react to an update of the roleId property, we regularly destroy and recreate ProjectUserRow components as part of user search.