✨Support token reload without restarting

[12345lcr]

What this PR does / why we need it:
In paravirtual mode, the CCM watches the mounted supervisor credentials and restarts the pod on any change. Since the credentials are delivered as a single projected Secret volume, routine token rotation triggered an unnecessary restart, even though client-go can reload the token on its own.

• Configures the supervisor rest.Config with BearerTokenFile instead of an inlined static BearerToken, so client-go transparently reloads the (short-lived, periodically refreshed) token from disk.
• Reworks the file watcher to skip restarts on token-only rotations. Because the projected volume updates atomically via a ..data symlink swap (fsnotify never names individual keys), the decision is content-based: a baseline hash of the restart-worthy keys (ca.crt, namespace) is captured at startup and re-checked on each event. Changes to those keys—or any change outside the credentials mount—still trigger a restart; an unreadable key fails safe by restarting.
• Adds unit tests for the watcher decision logic (token-only rotation, ca.crt/namespace changes, missing key, chmod, out-of-mount events) and updates the rest-config test for BearerTokenFile.

Backward compatible with the current non-expiring token and forward compatible with the planned short-lived token.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #1779

Special notes for your reviewer:
Manual Verification Complete

Step 1: Feature Deployment

• Update the CPI deployment to utilize the specific build containing the short-lived token feature.

Step 2: Basic Functionality Validation

• Provision a sample unprivileged LoadBalancer service deployment to verify normal end-to-end routing behavior.

Step 3: Resource Generation and Connectivity Verification

• Verify that the guest cluster LoadBalancer service successfully receives a valid external IP.
• Confirm that the corresponding VirtualMachineService resource is successfully generated in the Supervisor namespace.
• Validate traffic flow via a curl test against the external IP, ensuring the expected payload is returned.

Step 4: Token Rotation and Refresh Testing

• Manually delete the ProviderServiceAccount 's corresponding service account on the Supervisor plane to simulate a token rotation event.
• Monitor the system and verify that the resource successfully regenerates and issues a refreshed token.

Step 5: Temporary Disruption Observation

• During the transient window between service account deletion and recreation, the CPI pod expectedly reported brief Unauthorized API errors.

Note: This represents the expected systemic delay before service account regeneration.

Step 6: Recovery Validation

• Once the newly refreshed token synchronized down to the guest cluster, the CPI pod successfully authenticated, and all Unauthorized errors ceased.
• Concluded that recovery occurs gracefully without requiring a pod restart.

Step 7: Post-Rotation Lifecycle Verification

• Cycle the sample LoadBalancer service (delete and recreate) to ensure operational continuity post-rotation.
• Observed the expected asynchronous event loop timing (initial VirtualMachineService IP not found warnings while the infrastructure was provisioning), followed quickly by a successful EnsuredLoadBalancer status confirmation.

Step 8: Pod Restart Testing

• Manually modify the token secret's ca.crt field in the guest cluster to an invalid value to simulate a corrupted state.
• Confirm that the CPI pod automatically triggers a restart loop as expected when the ca.crt field change is detected.

Step 9: Environmental Recovery

• Revert the token secret's ca.crt field back to its original valid value.
• Confirm that the CPI pod restarts, successfully recovers its authenticated state, and returns to a healthy Running status.

Release note:

[k8s-ci-robot]

Hi @12345lcr. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 12345lcr
Once this PR has been reviewed and has the lgtm label, please assign bridgetkromhout for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[zhanggbj]

/ok-to-test