Adding transactional support for custom metadata collections

(This has been discussed separately, creating a ticket for traceability.)

Under CBD-3709 we are adding transactions support for the user to specify a custom metadata collection at the Transactions object level.  E.g. this:

Transactions transactions = Transactions.create(cluster, 

         TransactionConfigBuilder.create()

                .metadataCollection(metadataCollection)); 

This feature is aligned with 7.0.

This metadata collection will then be used for:

1. The polling cleanup will check this collection, instead of the default behaviour of checking the default collection of all buckets.
2. Any transaction created by this object will create and use ATRs on this metadata collection.

This allows a number of use-cases, including to support microservices (that may not have RBAC access to the default collection) and deployments where the user does not want to leak document keys from scope 'CustomerA' to ATRs in the default collection that could be read by 'CustomerB'.

This ticket is to request support from query engine for these metadata collections.  The exact details need further discussion but as a starting point I believe it would include:

1. A query parameter at the BEGIN WORK point for this metadata collection.  This will allow this feature to be used both from SDK and from REST/cbq.
2. Query to check that the user performing the BEGIN WORK has permission to read & write the metadata collection, using this parameter.  (This has been somewhat discussed under MB-42217.)

There are some open questions too:

• The polling transactional cleanup being done by query will only be checking the default collection on all buckets.  Perhaps it needs to also be adding any metadata collections it's told about to this list.
• If transaction A needs to read or write a document that's in transaction B, it will need to read B's ATR entry.  That ATR entry could be in a collection that this user does not have access to, and my understanding is that this could be hard to verify for query.