Make tidb_auth_token more flexible for general OAuth2/OIDC access tokens

## Feature Request

**Is your feature request related to a problem? Please describe:**

First, thank you for `tidb_auth_token` — it's a really nice way to integrate TiDB with an
external identity provider, and we've been enjoying using it.

While trying to reuse it with general OAuth2/OIDC **access tokens** (the token type many IdPs
hand out for programmatic / service-to-service access), I ran into a few assumptions that I'm
not sure how to work around, and I wanted to ask whether relaxing any of them would make sense
to you. I may well be missing an intended way to do this — if so, I'd be grateful for a pointer.

From reading the current implementation
([`checkAuthTokenClaims`](https://github.com/pingcap/tidb/blob/master/pkg/privilege/privileges/privileges.go#L434) and [`tidb_auth_token.go`](https://github.com/pingcap/tidb/blob/master/pkg/privilege/privileges/tidb_auth_token.go)),
the parts I got stuck on were:

1. An **`email` claim seems to be required** and must match the user's stored email
([privileges.go#L441-L442](https://github.com/pingcap/tidb/blob/master/pkg/privilege/privileges/privileges.go#L441-L442)).
Access tokens often don't carry `email` (it's more of an OIDC ID-token / userinfo claim),
and I couldn't find a way to opt out of this check. This was the main thing I got stuck on.
2. The **JWKS appears to be loadable only from a local file**
([`auth-token-jwks` config](https://github.com/pingcap/tidb/blob/master/pkg/config/config.go#L763),
read via [`ReadFile`](https://github.com/pingcap/tidb/blob/master/pkg/privilege/privileges/tidb_auth_token.go#L43-L44)).
I didn't see a JWKS-URL / OIDC-discovery option, so I think the key set has to be mirrored
to a file on each tidb-server and refreshed out of band — please correct me if there's a
better way.
3. The **`iat` freshness window looks hard-coded to 15 minutes**
([`defaultTokenLife`](https://github.com/pingcap/tidb/blob/master/pkg/privilege/privileges/privileges.go#L83)),
separate from the token's own `exp`, so longer-lived tokens get rejected even when not yet
expired.
4. **`sub` has to equal the TiDB username** exactly, with no mapping, so the issuer's principal
name has to line up with the DB user name.
5. **`aud` doesn't seem to be checked**, so I wasn't sure how to rely on audience scoping.

**Describe the feature you'd like:**

If it fits the project's direction, it would be wonderful if `tidb_auth_token` could be a bit
more flexible about the tokens it accepts. Even a small subset of the following would help a
lot — and of course I completely understand if some of these don't align with the design:

1. **An option to make the `email` claim optional**, falling back to `sub` as the identity when
the user has no email configured. This alone would be enough for our case, and seems like
the smallest change.
2. **An optional JWKS URL with periodic refresh** alongside the local-file option, so a key set
can be fetched and rotated directly (OIDC discovery would be a lovely bonus).
3. **A configurable `iat` window**, or relying on the already-validated `exp` for lifetime.
4. **Optional `aud` validation** against a per-user attribute, for those who want it.

I listed several only for context — please don't read it as a wish list. Even just the first
point would be a great help.

**Describe alternatives you've considered:**

- Running a small token-exchange service that re-packages our identity into the exact claim
shape TiDB expects (`email`, a fresh `iat`, etc.). This works, but it's extra moving parts
that I was hoping to avoid if there's a lighter path.
- Writing a separate custom auth plugin, though that seemed like it would duplicate most of
`tidb_auth_token` and be harder to maintain.

**Teachability, Documentation, Adoption, Migration Strategy:**

I'd expect anything here to be opt-in and backward compatible — existing setups that provide
`email` and a local JWKS file would behave exactly as before, with new behavior only when the
new options are explicitly set.

If any of this sounds reasonable, I'd be very happy to help — including discussing the design
or putting together a PR under your guidance. Either way, thanks a lot for considering it, and
for the work on TiDB.