6936 Implement email domain based groups

[poikilotherm]

What this PR does / why we need it:
Next to explicit groups, IP groups and Shibboleth groups, there is another valuable source of information to which association a user belongs to: a verified email.

Based on the domain part of the email, it's very easy to create groups based on affiliations. This might be handy for installations like the one from Leuven, where different universities share one instance (multi-tenancy). Our use case @ FZJ is to be able to open up for collaboration while automatically granting some rights to staff.

As this is independent from Shibboleth, this might be good for other instances like WZB (ping @RightInTwo), that create users via API.

Which issue(s) this PR closes:

Closes #6936

Special notes for your reviewer:

This is not only introducing a new group provider, but also refactors some other places in the codebase. Some noteable places:

• Add a simpler verification check function for email addresses and make use of it. It's much easier to understand now and easier to extend (looking at Refactor authentication provider JSON configuration #6694).
• Extend the usage of ExceptionMappers in REST API endpoints. There are a lot of places with lots of boilerplate and catch all like try-catch code. This makes the code more verbose and violates DRY principle. Obviously I didn't touch too much of other code to keep the scope of this PR as small as possible. (But didn't want to encourage the use of catch-alls any further...)

Suggestions on how to test this:

• Deploy, but don't yet publish the root dataverse.
• Create a new mail domain group
• Add the group as member or similar to the root dataverse
• Create a user with a group-matching mail address
• Verify user email
• Get access to the root dataverse
• Delete the permission
• Verify permission is gone

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Nope.

Is there a release notes update needed for this change?:

It should be mentioned this is a new option to create groups of people.

Additional documentation:

Nada.

[coveralls]

Coverage increased (+0.04%) to 19.63% when pulling 76ae927 on poikilotherm:6936-domaingroups into 75742b9 on IQSS:develop.

[poikilotherm]

This is done I think. Can somebody please do a review? Thx!
BTW it works already on our production instance 😄

[landreev]

This is done I think. Can somebody like do a review? Thx!
BTW it works already on our production instance 😄

Will do, thank you!

[landreev]

Somebody else here has pointed out that there is a connection with issue #3438; in a sense that, if we rely on users having verified emails for the purposes of group membership, not being able to verify it becomes more of an issue.
Since you have been using these email groups in production, have you done anything to address #3438? (one possible solutions appear to be to just always show this button below - ?)

[poikilotherm]

Nope, I didn't. I was going to lean on auth provider support for this. Is this still an issue? It's 4 years old and a lot happened since then. If we encounter these problems again, I could take a look at this...

[landreev]

It appears that it has never been fixed precisely because it was not much of a serious issue for anyone (I didn't have any recollection of it). And form what I'm reading, that condition only happens if a user tries to refresh the page at the wrong time during the verification... The fact that you haven't heard many complaints about it is somewhat reassuring.
We'll address #3438, now that we have an extra reason to do so. I asked in part because I was wondering if the refactoring you suggested in the comment above might by itself solve it - but no, I don't think so.

[poikilotherm]

Yeeeeehaw! 🤠 Thanks for merging @kcondon