Introduce a role.settings config object and move 'Administrator role' out of the Role entity config

Fixed issue comment link in the IS.

Added the following to the bottom of Remaining Tasks:

We may also want to find or create a follow-up issue for making the Anonymous and Authenticated roles configurable. The machine names of these roles are currently hard-coded in Drupal\Core\Session\AccountInterface as const ANONYMOUS_ROLE = 'anonymous' and const AUTHENTICATED_ROLE = 'authenticated'.

Here's another candidate setting to move from 'Account settings' to 'Role settings':

Name
[ Anonymous ]
The name used to indicate anonymous users.

So this setting I've often found a bit confusing, because it is actually the name that will be used for the Anonymous user (UID 0) not the Anonymous role. For example, when someone posts a Comment on a Node, if they are not logged in their comment will be posted as UID 0 and if they don't supply a name, this is the value that will be used for the name.

So it's technically in the right place, but definitely a confusing setting and probably needs a issue found/opened to see how we can improve it. The separating of "Account settings" and "Role settings" probably makes this slightly less confusing now actually.

Not sure if this and #3 make sense in the scope of this issue, or if we should spin each one off to a separate follow-up...

Yeah, I'd say let's just try and keep this issue about adding the config object, since it'll also need an update hook and schema changes, and then file those issues but postpone them on this one. I think separate issues because the roles both do different things and so we would want to make sure we give them the space to be properly discussed.

Thanks.

I haven't given this issue a good read, but I'm mentioning it because there may have been a reason that a config object wasn't just created from the beginning #2435075: Implement admin role as a flag on the role storage, simplify permissions page, remove user_modules_installed, so I just want to make sure we're aware of any reasoning there.

I'll have a skim of it, will post back if I find anything relevant.

I had a thought! This might be a backwards compatibility break, consider this scenario:

1. A profile/distribution has role configs exported, they have a role named "sys_admin" as the admin role, they do not have a role named "administrator";
2. On upgrade to (let's say) 9.3.x sites that use this profile/distribution get updated, the new object is added, it references the "sys_admin" role, all is good.
3. The profile/distribution is installed with 9.3.x, however the role configs it ships are now updated to take account of this new config object.
4. The 9.3.x sites are installed with the "sys_admin" role, however no role is marked as the administrator role because the profile/distribution did not include the role.settings object.

Now, currently this scenario is not a huge problem because UID 1 will still have all permissions due to the special behaviour of that user, however when #540008: Add a container parameter that can remove the special behavior of UID#1 is committed, in theory these sites might be in a situation where UID 1 does not get the "sys_admin" role and so does not have any admin users.

Now, I'm not sure if this is a situation we need to worry about, this won't break existing sites, only new sites that are installed with this very specific scenario, therefor it's really easy to figure out that something is broken and for the relevant profiles/distributions to update their configuration. I guess the question is, does out BC policy cover configuration changes like this?

Also, I'm making an assumption here that the user module is going to provide a default config that references "administrator" as the admin role, as a fallback to cover most cases. If we do that, then that further reduces the likelihood that this scenario would ever come up, because most profiles/distributions probably follow the pattern that Core established of having the admin role be named "administrator". So maybe this is such an edgecase that it's just not even worrying about.