Prepare for a smooth transition for new Deleted User

[sssoleileraaa]

Description

Fixes #1143
Closes #1157

This PR removes the /user api call and instead uses the /users endpoint to update and manage the current user as well as all other users. Since an API call is removed and a new one is introduced, the functional test cassettes needed to be regenerated (see the cassettes section in the README for more details if needed).

Followup: Once freedomofpress/securedrop#6225 is released, we can remove the old way of creating users based on a reply's journalist_uuid. For now, I left this in to continue to support showing replies associated with no corresponding user account on the server (/users doesn't actually return any user for replies with a "deleted" UUID)

Test Plan

• Confirm Deleted user is not fully removed from client database after a sync #1143 is fixed
• Checkout this PR branch and confirm that deleted users continue to show up (you can run make dev to create a dev server with a deleted user- look for the sparkle icon in the journalist badge next to replies)
• Change the name of the current journalist (change username, firstname, lastname) and confirm change in the corresponding journalist account badge and reply badge
• Repeat step above for a journalist that is not currently logged into the client

Future-proof test

• Restart the server from the code changes here: Use special "deleted" journalist for associations with deleted users securedrop#6225 and confirm that deleted users continue to show up

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes

If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:

• I have updated the AppArmor profile
• No update to the AppArmor profile is required for these changes
• I don't know and would appreciate guidance

If these changes modify the database schema, you should include a database migration. Please check as applicable:

• I have written a migration and upgraded a test database based on main and confirmed that the migration applies cleanly
• I have written a migration but have not upgraded a test database based on main and would like the reviewer to do so
• I need help writing a database migration
• No database schema changes are needed

[legoktm]

Just did a code review for now, I'll test it tomorrow.

[conorsch]

Works well for me! Tested against a server running on current head of develop, the syncing was accurate. Notably, both the username and uuid were set to "deleted".

After switching the server to use PR freedomofpress/securedrop#6225 and repeating local testing, the sync of all attributes was still accurate, with the notable difference that the original uuid for the first deleted user in the client db was preserved. Creating and deleting multiple users did not create additional "deleted" users, nor did it overwrite the uuid of of the special "deleted" user in the client db, as expected.

[conorsch]

I've approved, but am intentionally not merging, so that @legoktm can take a close look in tandem with related functionality in freedomofpress/securedrop#6225.

[legoktm]

Went through the test plan and everything LGTM! And it helped me find a bug in my PR: freedomofpress/securedrop#6225 (comment).