Enable multiple providers

Expected Behavior

Solution should support authentication via multiple providers and not only one, including support of multiple providers of the same type (i.e 2 different okta providers).

Current Behavior

Oauth2-proxy currently supports only 1 provider at a time (and all its provider related configuration is bound to it). Additionally, currently it is not trivial to ingest recurring structured configs (in our case providers) in an elegant way while supporting all possible ingestion methods.

Possible Solution

Tap into the big structural config refactoring (https://github.com/oauth2-proxy/oauth2-proxy/issues/532) to configure multiple providers in a YAML file and once provider is chosen pass it in a designated provider cookie through the chain.

Steps

1. Ingest providers via custom yaml loader and attach to main options:

- provider: okta
   provider_display_name: okta_1
   provider_ca_files:
     - file1
     - file2
- provider: azure
   provider_display_name: azure_1
...

1. Loop over each provider configuration info and perform validation on each, with the goal of creating a providers map[string]providers.Provider (instead of the single provider providers.Provider) - a map from provider display name to provider struct.
2. Load a template that supports multiple providers (sorted).
3. Initiate a proxy with provider cookie field and add support to each provider with its own session chain.
4. Once provider chosen, attach it to the provider cookie, and extract it from the map when provider related actions are needed.

Additional comments / Caveats

1. Provider display name must be a mandatory field to enable support of multiple providers of the same type.
2. Verify that suggested changes do not damage the s2s flows supported by OIDC (i.e https://medium.com/in-the-weeds/service-to-service-authentication-on-kubernetes-94dcb8216cdc) - haven't gotten the time to review this fully yet, so I'll better add this here.
3. skip-provider-button will be irrelevant in case more than 1 provider is configured.
4. Need to be careful dividing configs that are related to each provider and common configs between all providers (if there's any) - i.e how to handle provider-ca-files? one for each provider or general to all defined providers (used to define cert pool of http.DefaultClient))?
5. Open question - how Redis and Cookie stores need to support the provider cookie? one option is to add providerCookie to cookie store and somehow translate that into the ticket version on the Redis alternative..?