This transaction will

1. Unset container for any upload where the viewer.userID matches the container and uploader. This is to make sure any previous image avatar uploads have their container cleared. If the previous avatar was of type emoji or ens, this query is effectively a noop. However, the query should be lightweight since we have an index on container and we only expect <=1 row in the result set.
2. We set the container for the mediaID in the request to viewer.userID if the upload belongs to the user making the request (uploader = ${viewer.userID}) and the container is NULL. If the update request was of type image, this will ensure the container is correctly set. If the update is of any other type, this is effectively a noop. Again, the query should be lightweight since we have an index on container and we only expect <=1 row in the rsult set... and it should be cached from the previous query.
3. We update the avatar column of the users table with the newAvatarValue from the request. If mediaID is set (AKA we're dealing with an image avatar), we make sure that an upload with the corresponding ID exists in the uploads table via a SELECT subquery AND that the container is set to the viewer.userID AND that the upload "belongs to the user" (uploader = ${viewer.userID}).

This is all wrapped in a single transaction so we don't end up in a broken state where eg the user avatar is set to an image that doesn't exist in the uploads table (which causes a crash on native as I accidentally discovered during testing).

1. Set emoji avatar
2. Make sure it's set correctly
3. Set image avatar
4. Make sure it's set correctly
5. Clear user avatar
6. Make sure it's set correctly

Basically I set and unset user avatar multiple times, tried setting the image avatar with the same uploadID multiple times to make sure the endpoint is idempotent, etc etc.