How can I access OpenIdConnectProvider classes in 7.4 U34+?

Issue

The Liferay classes com.liferay.portal.security.sso.openid.connect.OpenIdConnectProvider; and com.liferay.portal.security.sso.openid.connect.OpenIdConnectProviderRegistry; were removed in U34+ by LPS-150092.
How can I replace them in my customization?

One way to achieve replacement classes is to recreate the OpenIdConnectProviderRegistryImpl.findOpenIdConnectProvider method through customizations.
- This will require retrieving all entries from the _configuration table which begins with com.liferay.portal.security.sso.openid.connect.internal.configuration.OpenIdConnectProviderConfiguration, and then iterating through and find the one with the matching providerName.
- We did this before via an in-memory map (see LPS-150092 for more details). Basically, upon server startup or configuration addition/subtraction, we would update the map as providerName (key) to configuration (value). From there we could easily look up the configurations.
- You could also skip the map and just perform the configuration retrieval and filtering per request.
Alternatively, you may be able to access the data using the following script, since we now create an OAuthClientEntry for each OpenID Connect connection.
- ```
com.liferay.oauth.client.persistence.service.OAuthClientEntryLocalServiceUtil.getOAuthClientEntries(-1, -1).each { client ->
 out.println(client);
}
```

OpenIdConnectProvider configurations are are no longer stored locally with the inclusion of LPS-150092, so we cannot easily retrieve them with a class like OpenIdConnectProviderRegistryImpl.findOpenIdConnectProvider. This code change can be reviewed at https://github.com/brianchandotcom/liferay-portal/compare/03162209ce...23b907d1cf.
Because the OpenIdConnectProvider objects were meant to be gathered dynamically depending on login/authentication needs rather than to be used on their own, everything was moved to the backend, where it isn’t very accessible with public APIs.
The OpenIdConnectProviderRegistryImpl class has been historically internal, as its contents were never meant to be leveraged externally.