Allow for OIDC Issuer URL to mismatch the one served by its metadata

### Current Behavior

Hello,

As we're investigating Dependency Track, I did setup a test instance.
We are running in OpenShift, which has its own users/groups, while integrated with our corporate OIDC provider. Deploying applications to OpenShift, I need to integrate with its users.
I managed to get something working, using Dex, which implements OIDC, while integrating with OpenShift.

Works great, if I configure my OIDC_ISSUER / alpine.oidc.issuer pointing to the public FQDN exposing my Dex instance in OpenShift.

However, I know I could get this to work, with other applications (namely ArgoCD) ... Configuring application to query my Dex instance, connecting to the Service, in OpenShift SDN (without requiring the connections to leave/re-enter my cluster).
Yet when I attempted to configure Dependency Track components querying my internal Service name, during login, I would see something like this in apiserver logs:

```
ERROR [OidcConfigurationResolver] Failed to fetch OIDC configuration from issuer "https://my-internal-endpoint.svc:5556"
com.nimbusds.oauth2.sdk.GeneralException: The returned issuer doesn't match the expected: https://my-external-endpoint
```

Reading about https://github.com/DependencyTrack/dependency-track/issues/2574#issuecomment-1462339141
I understand that Dependency Track does require configuration issuer URL to match the one served from metadata.
I'm not sure this has to be mandatory.
Surely, in OpenShift/Kubernetes context, when two pods are running in the same namespaces, it's better not to have their communications exiting SDN to re-enter.

It works great when I open those flows, allowing Dependency Track to connect towards the loadbalancers serving Ingresses on behalf of my namespace. However those loadbalancers grant access to several namespaces just like mine, in my tenant.
As we're considering integrating Dependency Track to our own CI, it would make it an easier sale, not having to request that flow.
Still we're very please with what we see. Great work!

### Proposed Behavior

When API server connects to OIDC issuer, it could do so through some internal domain name.

One way may be to translate FQDN/port from discovered metadata, trusting instead the OIDC_ISSUER configuration we know of.
Or we could provide with additional internal endpoints -- in addition to the main issuer URL, you probably need to know about the token_endpoint & userinfo_endpoint? Anything else?

End-user will still query public endpoints as it connects to Dex/OIDC endpoints.
Only Dependency Track components should prefer private connectivity when possible/available.

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested