PKI and Kerberos providers shouldn't automatically log user in if Login Selector is enabled

[azasypkin]

Since PKI and Kerberos authentication providers don't need to interact with the user and perform any type of user-facing redirect to log user in they can "automatically" create a new session whenever they happen to process an unauthenticated request (XHR or not, assuming it requires authentication).

Historically when any of these providers was used it was usually a sole authentication mechanism and such automatic behavior for any user request that can be authenticated made sense. But with the introduction of the Login Selector we may know exactly when user explicitly wants to log in. Login is an important event and performing it only when it's really desired makes a lot of sense, and, as a bonus, it would also help us to not exacerbate issue likes #77411 when any random request that is made from the login/logged-out page can automatically log user in again.

But we still should account for the case when optional Login Selector is not available. So we can potentially try to create a new session only when:

• We receive a non-XHR unauthenticated request and Login Selector is not enabled.
• When we receive either XHR or non-XHR request with the existing session which relies on the expired access token (or refresh token in case of Kerberos), irrespective to the Login Selector state.
• [PKI only] When we receive either XHR or non-XHR request with the existing session which relies on the certificate chain that is different from the one associated with the current request, irrespective to the Login Selector state.

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)