fix ZTIS certificate caching

[mpern]

Context

Fixes the following issues:

• https://sap.stackenterprise.co/questions/90517
• https://sap.stackenterprise.co/questions/90606
• ztis keystore is not refreshed after expiry #1134

Feature scope:

refresh the cached ZTIS keystore if certificate is close to expiration.
otherwise requests fail if the backend is up for more than 7 days.

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Documentation updated
• Release notes updated

[MatKuhr]

Thanks for the suggestion, but I'm not yet convinced this PR changes much / fixes the issue. Currently, the code relies on the object reference comparison, and while that is certainly less robust than actually comparing certificates as we had intended, the logic should still work.

If the underlying SVID changes, the X509Svid POJO should also be re-instantiated, so the object reference should be different and the equals comparison will fail. I don't see how the POJO could remain the same object reference while the underlying SVID changes from looking at the code.

[mpern]

I removed the object reference comparison from ZeroTrustIdentityService already.
As mentioned in one of the linked issues, the spiffe library removed Lombok from their project which also removed the deep equals the current implementation relies in.

isKeyStoreCached now checks if

• spiffe ID is the same (sanity check)
• if the workload / leaf certificate is close to expiration

Since getX509Svid uses the spiffe library to get the actual client cert from the workload API, a cache miss ensures a new, valid and different cert than the one before.

That said, I need to double check the new tests for ZtisClientIdentity if they properly reflect a rotation scenario

[mpern]

Now that I typed it all out I get your point. How can the pojo be equal if the cert was rotated 🤔

[MatKuhr]

@mpern we've now added a change that should allow the SDK to automatically detect rotations for the OAuth2 token flows: #1142

While not 100% confirmed this will resolve all rotation issues, it should be an improvement. Thus, closing this PR for now.

Still, the current logic relies on comparing the KeyStore object references, which isn't ideal. If you like, once the fix is confirmed to work, please feel free to update this PR and re-open to change that aspect specifically.