Access & validation mismatch editing a registration on a disabled host

I don't have a specific proposal for this yet, I'm just filing this issue to flag this as a @todo.

I find the intertwined and often not DRY logic for access, HostEntityInterface::isEnabledForRegistration(), HostEntityInterface::isUserRegistered(), and RegistrationConstraintValidator rather scary. I suspect that a fundamental refactor is needed in this area. It's as if this module has done an absolutely fantastic job of growing to handle all kinds of use cases, but the growth has got to the point where it shows that one of the existing pillars needs an overhaul.

I'm actively thinking about this and hope to make a proposal.

Widened this to include creating registrations too.

If we can do 📌 HostEntity::isUserRegistered() and isEmailRegistered() don't consider edge cases Active then my question becomes:
could we make use of these new HostEntity methods in RegisterAccessCheck and RegistrationAccessControlHandler?

One possible concern is that they may be expensive, and so performance when viewing a list of hosts might degrade. I'm tempted to think we should do it anyway, rely on the render caching, and add more specific custom caching if we need to.

There are a number of things in play here:

* Refactoring to share more code between access and validation - I like this idea but let's set this aside since https://www.drupal.org/project/registration/issues/3464736 📌 Replace HostEntity::isEnabledForRegistration Active covers it

* Registration is disabled after the form has already been displayed, e.g. capacity is reached while a new registration form is being filled in - yes, bad UX since there will be an error no matter what the user inputs, but generally, you cannot rely on access control to avoid constraint checks for this reason

* Some validation is dependent on submitted values, e.g. in many cases the registrant is unknown until submit - some checks can only occur in validation, for example the "allow multiple registrations for the same user" check

That leaves us with:

* A non-administrator attempts to edit a registration after registration is disabled, and the disabling occurs before the Edit tab is rendered - we can do something about this one; currently "update" permission is checked in access control - the constraint validator performs the same checks but adds an extra one for this use case. I think the validator is correct in doing this extra check, but it could be added to access control as well.

New registrations are checked by RegisterAccessCheck - although it only checks the main status switch in the settings, that should generally be accurate, and the form displays a message instead of the fields when it isn't. So going to leave that use case alone.

Automatically closed - issue fixed for 2 weeks with no activity.