feat(datastore): add support for request tags

[rahulmane-goog]

This PR introduced sending request tags for different datastore requests. The tags can be passed using 2 mechanisms:

1. Instance Level tags.
2. Request Level tags.

• RequestOptions is the proto that holds all the instance and request level tags and is a part of all request protos.
• DatastoreOptions allows the ability to set the instance level tags using setRequestTags. Any operation executed via this Datastore client automatically includes these global request tags in the outbound RPC request payload.
• RequestOptionsHelper an internal utility that combines instance-level tags from DatastoreOptions with any request-level RequestOptions protobuf message before building the wire request.
• DatastoreExecutionOptions is a holder object for all different options like ExplainOptions, RequestOptions and ReadOption.
• Overloaded versions for taking in the DatastoreExecutionOptions for each of the following operations:
  • put
  • get
  • fetch
  • delete
  • newTransaction
  • commit
  • rollback
  • allocateId
  • reserveIds
  • runQuery
  • runAggregationQuery
• Each of these overloaded versions copy the request tags into the request protos.

[gemini-code-assist]

Code Review

This pull request introduces support for passing and merging RequestOptions (such as request tags) in Datastore queries and aggregation queries, allowing both instance-level and request-level tags to be propagated. The feedback highlights a critical issue where instance-level tags are ignored when query-level RequestOptions are not explicitly provided in QueryResultsImpl and AggregationQueryRequestProtoPreparer. Additionally, the reviewer suggests simplifying the varargs withRequestTags overload in Datastore by delegating to the List version, and adding a test case to verify that instance-level tags are correctly populated and sent with queries.

[rahulmane-goog]

Please review

[jinseopkim0]

ci / lint is failing. Could you please take a look?

[rahulmane-goog]

ci / lint is failing. Could you please take a look?

Fixed

[lqiu96]

Thanks! I think the changes are looking good. I've added another round of comments and smaller changes for readability.

One question that probably depends on plans regarding stability of request tags: When do we feel comfortable marking it from @BetaApi to GA? I'm thinking that the methods in the Datastore interface that do not have DatastoreExecutionOptions probably should be marked with @ObsoleteApi so users know to migrate over to the stable public surface. But everything is marked with @BetaApi which may not be something we should have users migrate to.

Perhaps it may be better to mark the requestTag getters/ settings with @BetaApi instead? Since 2/3 of DatastoreExecutionOptions (Explain and Read Options are stable, just the request tags is new)

[rahulmane-goog]

Thanks! I think the changes are looking good. I've added another round of comments and smaller changes for readability.

One question that probably depends on plans regarding stability of request tags: When do we feel comfortable marking it from @BetaApi to GA? I'm thinking that the methods in the Datastore interface that do not have DatastoreExecutionOptions probably should be marked with @ObsoleteApi so users know to migrate over to the stable public surface. But everything is marked with @BetaApi which may not be something we should have users migrate to.

Perhaps it may be better to mark the requestTag getters/ settings with @BetaApi instead? Since 2/3 of DatastoreExecutionOptions (Explain and Read Options are stable, just the request tags is new)

We are planning to do a public preview of supporting request tags , the backend changes are already enabled. Should I create a separate bug for doing what you suggested?