(chore) renew token 10 minutes before expected renewal time

[gianlucam76]

Sveltos renews tokens with a 30-minute buffer added to the RenewTokenRequestInterval. For example, if the interval is two hours, Sveltos requests a token valid for two hours and thirty minutes. This buffer ensures that Sveltos has sufficient time to detect the need for renewal and perform the renewal process before the token actually expires. The 30-minute buffer accounts for the time that elapses between token generation and the next scheduled renewal check (which occurs after the full RenewTokenRequestInterval).

Imagine Sveltos generates a token and then waits the full two hours (the RenewTokenRequestInterval) before checking if it needs renewal. If the token's actual expiration was exactly two hours, it would have already expired by the time Sveltos checks again. The 30-minute buffer prevents this race condition. It gives Sveltos a window of time to detect the nearing expiration and renew the token.

If a user sets RenewTokenRequestInterval to 48 hours (or any value close to the maximum token lifetime allowed by the underlying platform, like GKE), Sveltos's standard approach of adding a 30-minute buffer can cause issues. While Sveltos attempts to generate a token valid for 48 hours and 30 minutes, GKE (and other platforms) may impose a maximum token lifetime, often around 48 hours. This means the requested token lifetime will be truncated to the maximum allowed (e.g., 48 hours). Consequently, by the time Sveltos checks for renewal (after the full 48-hour RenewTokenRequestInterval), the token might have already expired.

To address this, the renewal logic is adjusted. Instead of waiting the full RenewTokenRequestInterval, Sveltos now checks for renewal at RenewTokenRequestInterval minus a small buffer (e.g., 10 minutes). This ensures that Sveltos checks for renewal before the maximum token lifetime is reached, even if the requested token lifetime was truncated by the platform.
This buffer is chosen to be greater than or equal to the minimum allowed token lifetime.

This pull request also ensures the RenewTokenRequestInterval is appropriate for the actual token expiration. For example, if the user configures RenewTokenRequestInterval to renew tokens every three days, but the generated token's maximum lifetime is only two days (what will happen with GKE for instance) Sveltos will automatically adjust the RenewTokenRequestInterval to two days. This prevents Sveltos from attempting to renew a token that will have already expired.