This adds a link for each authentication providers that are listed in
/my/preferences/account in the "Associated Accounts" section.
This is particularly useful when Discourse is being used in the PWA or
in the DiscourseMobile app where there's no browser bar available and
the only way to visit the provider's website is to open a browser
window.
That way, they can _just_ click the provider's name.
Internal ref - t/156255
---
**BEFORE**

**AFTER**

This improves the error message(s) displayed when an error happens while
using a social login to log in / sign up into a Discourse community.
Unfortunately, we can't be super precise in the reason behind the error
(it can be the user clicked "cancel" during the authorization phase, or
any of the plethora of other possible errors) because the reason isn't
provided (either for security reasons, or because it's just hard to do
so in a reliable & consistent way accross all social logins).
The best I could do was to
- add the name of the "social login" provider in the error message
- tweak the copy a bit for the different cases handle
- fix the CSS/HTML to match the one used by the main application
In order to show the name of the provider, we use either the "provider"
or the "strategy" query parameter, or use the name of the authenticator
(if it's the only one enabled).
Internal ref - t/153662
---
**BEFORE**

**AFTER**

We're going to change the default return value of the `primary_email_verified?` method of `Auth::ManagedAuthenticator` to false, so we need to explicitly define the method on authenticators to return true where it makes sense to do so.
Internal topic: t/82084.
This commit adds an additional find_user_by_email hook to ManagedAuthenticator so that GitHub login can continue to support secondary email addresses
The github_user_infos table will be dropped in a follow-up commit.
This is the last core authenticator to be migrated to ManagedAuthenticator 🎉
This reduces chances of errors where consumers of strings mutate inputs
and reduces memory usage of the app.
Test suite passes now, but there may be some stuff left, so we will run
a few sites on a branch prior to merging
If a site is configured for GitHub logins, _**and**_ has an email domain
whitelist, it's possible to get in a state where a new user is locked to
a non-whitelist email (their GitHub primary) even though they have an
alternate email that's on the whitelist. In all cases, the GitHub
primary email is attempted first so that previously existing behavior
will be the default.
- Add whitelist/blacklist support to GithubAuthenticator (via
EmailValidator)
- Add multiple email support GithubAuthenticator
- Add test specs for GithubAuthenticator
- Add authenticator-agnostic "none of your email addresses are allowed"
error message.