Refactor rendering to generate user accounts instead of using existing accounts

[Ambient-Impact]

Currently, RepresentativeRenderUserInterface::getUserToRenderAs() works by finding a user account with the required combination of roles but this is potentially insecure if this somehow reveals something to a user account that should not have access to that information, such as admin information or data.

drupal-omnipedia-user/src/Service/RepresentativeRenderUserInterface.php

Line 48 in 858e58a

public function getUserToRenderAs(

drupal-omnipedia-user/src/Service/RepresentativeRenderUser.php

Line 139 in 858e58a

public function getUserToRenderAs(

[Ambient-Impact]

Potential idea if it's not possible to render as a user that has not been saved to the database (i.e. a temporary user): create and save user accounts with the following traits:

• Clearly labelled unique user account name and generated (non-existent) email address; e.g. "Changes render user N" / "[email protected]" ("N" being a counter for uniqueness; domain name should be taken from system.site.mail config).
• Must be assigned the same role(s) as identified "real" user accounts it's the counterpart to.
  • What about Permissions by Term and other access grants?
• Blocked so that no one can access it; this should theoretically still allow rendering?
• Maybe provide some kind of warning if someone who can administer users tries to delete such an account so they know why they exist/are being created?

Additionally, it'll be a good idea to store a array/map of these generated user accounts so they can be easily retrieved. Perhaps they can be stored in the State API, along with a corresponding cache item which is assigned all the relevant cache tags (e.g. user:123, user:124, etc.) so that we know to rebuild the state entry if any of the accounts are modified or deleted.