x509 cache hint for registration entries

[ValFadeev]

This is a draft PR aiming to implement some of the suggestions discussed in #6129. It adds a new field to RegisteredEntry represented by an opaque protobuf-encoded message. The message is meant to contain flags and other fields guiding the agent's behavior with respect to pre-fetching and caching of X509 SVIDs. The intention is to reduce unnecessary work performed by the agent, in case the client is unlikely to ever ask for an X509 SVID and prefers JWT instead. For now only one boolean flag JWTOnly is introduced. Other fields may be added later to fine-tune the logic and cover various edge-cases.
The bulk of this draft is to define the new field in the message definition, update the datastore and have the existing tests pass. The actual usage of the field in fetchEntries is purely indicative and requires further consideration.

Pull Request check list

• Commit conforms to CONTRIBUTING.md?
• Proper tests/regressions included?
• Documentation updated?

Affected functionality

• adds a new field to RegisteredEntry and the underlying datastore table
• allows flagging registration entries as preferring JWT SVID over X509
  Description of change

Which issue this PR fixes

Fixes #6129

[sorindumitru]

We discussed this today and we think this would be more useful if it was a generic flag field that we can use in the future for non x509-svid cache flags.

For the flag itself, we think disable_x509_svid_prefetch would be better since it allows us to specify more easily which SVID types should be prefetched. This might come in handy if we get a new SVID type, for example WIT-SVID.

[amartinezfayo]

Hi @ValFadeev, are you planning to go back to this PR?

[ValFadeev]

Hi @amartinezfayo, apologies for the delay. I had a few conflicting priorities lately, but I do plan to pick this back up over the coming week.

[ValFadeev]

@amartinezfayo offering this for another review. I am not sure I implemented the semantics of an optional field the right way when loading from row. I also understand this change may have to be split in two, with the schema migration going first. But hopefully, this gives an outline of the functionality, as it was last described.