Support automatic service account token refresh for in-cluster configurations

[dev022022]

Problem

When running lightkube inside a Kubernetes pod, the service account token is mounted as a projected volume at /var/run/secrets/kubernetes.io/serviceaccount/token.
Starting with Kubernetes 1.22+, these tokens are bound and have a limited lifetime (1h by default, configurable via --service-account-max-token-expiration).

Previously, from_service_account() read the token file once at startup and stored it as a static string. When the token expired, all subsequent API calls failed with HTTP 401 — requiring a full client restart to recover. This is a problem when lightkube is for example used in a long running Kubernetes operator.

This is a well-known problem that Go's client-go solves via its fileTokenSource / cachingTokenSource / tokenSourceTransport mechanism, which re-reads the token file and retries on 401.

Solution

This PR adds a BearerTokenFileAuth class that follows in general the same pattern:

• Caches the token after the initial file read (avoids unnecessary I/O)
• Re-reads the token from disk and retries when the server returns 401 (the kubelet writes a fresh token before the old one expires, so the rotated token is always available on disk)
• Works for both sync and async client flows

Backward compatibility

Fully backward compatible:

• user.token is still populated by from_service_account(), so existing code that reads config.get().user.token continues to work.
• For kubeconfig-based configurations (where token_file is None), behavior is completely unchanged — the existing BearerAuth with static tokens is used.
• token_file is only set programmatically by from_service_account(); it does not interfere with YAML kubeconfig parsing.

I also tried to adapt the documentation accordingly. If I missed something or changes are necessary from your pov, please let me know and I will adapt the PR.