Respect increment value in grace period calculations (api/LifetimeWatcher)

[averche]

Fixes: #14638

Background

api.LifetimeWatcher is a tool that helps to monitor and periodically renew expiring token or credential leases. It determines a grace period based on a given lease duration and attempts to renew the lease within the grace period. The callers of LifetimeWatcher can optionally specify Increment value in seconds, which is sent to the vault server and is meant to override the token's TTL value, if respected by the server.

The issue

This means that for long lived leases, a client cannot submit it's own increment value that is less than the leases grace period without triggering and immediate return (without sleeping).

Change

This PR will make sure that the grace period is calculated based on the minimum of the remaining lease duration & interval (if specified).

How was this tested

I added a short_increment_duration test renewer_test.go.

Additionally, I was able to successfully reproduce the issue in hello-vault-go. Before the fix, setting an increment value lower than the token's actual TTL resulted in an early renewal and the following error every time renew was called:

URL: PUT http://vault-server:8200/v1/sys/wrapping/unwrap
Code: 400. Errors:

* wrapping token is not valid or does not exist. If the AppRoleAuth struct was initialized with the WithWrappingToken LoginOption, then the secret ID's filepath should be a path to a response-wrapping token

When I built against this branch, the error disappeared and the renew period was updated to the increment value minus grace period as expected.

[VinnyHC]

Nice! This looks good to me.

[digivava]

Good stuff! I'm approving because I think this makes sense, but just checking one thing: In the docs it says "[The increment value] is not an increment at the end of the current TTL; it is an increment from the current time."

That doesn't change anything here, right? I don't think it does but just double-checking.

[averche]

Good stuff! I'm approving because I think this makes sense, but just checking one thing: In the docs it says "[The increment value] is not an increment at the end of the current TTL; it is an increment from the current time."

That doesn't change anything here, right? I don't think it does but just double-checking.

I don't think it changes things since we used to calculate the grace period based on the remaining TTL (which is also from the current time, so it make sense to apply the same logic to the increment value)