Add Kubernetes TokenReview support to K8sSA provisioner

[murzakanovim]

Summary

• add the in-cluster Kubernetes TokenReview path that was left as a TODO in kubernetes service account provisioner #133
• preserve the existing public-key validation path when publicKeys is configured
• route modern bound ServiceAccount tokens with configurable Kubernetes issuers to K8sSA
• add focused tests and a Kubernetes RBAC/projected-token example

Behavior

When a K8sSA provisioner omits publicKeys, step-ca initializes a minimal
in-cluster TokenReview client using the standard Kubernetes API environment,
mounted CA bundle, and ServiceAccount credential. If publicKeys is present,
the existing local JWT verification behavior is unchanged.

The TokenReview request includes the operation-specific step-ca audiences. The
response must be authenticated and contain an audience accepted by the current
sign, revoke, or SSH-sign endpoint. The authenticated username must use the
standard system:serviceaccount:<namespace>:<name> form; namespace,
ServiceAccount name, and UID are populated from the TokenReview response rather
than unverified JWT claims.

Modern ServiceAccount tokens no longer have a fixed issuer. Routing therefore
uses the standard ServiceAccount subject plus Kubernetes claims as an
unverified hint. The selected K8sSA provisioner still authenticates the token
with TokenReview before trusting any identity.

The implementation fails closed. It does not fall back to public-key
validation when the Kubernetes API is unavailable. The reviewer credential is
read on every request so kubelet rotation is picked up without a restart.

Scope

This implements the generic same-cluster path only. It does not add remote
kubeconfig or multi-cluster routing. K8sSA certificate CN/SAN authorization is
unchanged and remains the responsibility of name policy, templates, or
webhooks.

Verification

• go test ./authority/provisioner
• go test -short ./...
• go test -race ./authority/provisioner
• go vet ./...

Design feedback requested

• Is omission of publicKeys the preferred opt-in for in-cluster TokenReview,
  or should this be represented by an explicit configuration field?
• This draft deliberately requires a projected token whose audience matches a
  step-ca endpoint instead of accepting the Pod's default Kubernetes API
  audience. Is that strict audience behavior desirable for K8sSA?

[CLAassistant]

All committers have signed the CLA.

[murzakanovim]

@dopey Hi Max! Can u review this pr? You left TODO 7 years ago, I think its time to implement TokenReview way