Implement support for metadata associated with read-write transactions

[josephschorr]

This will allow callers of APIs such as WriteRelationships and DeleteRelationships to assign metadata to the transaction that will be mirrored back out in the Watch API, to provide a means for correlating updates

First part of #966

Each datastore has a different means of correlating between the transaction and the associated change(s) coming out of the watch API:

• Memdb: The metadata is stored on the changes struct
• Postgres: A metadata column was added to the transactions table
• MySQL: A metadata column was added to the transactions table
• Spanner: A transaction tag is used to correlate the transaction and the metadata is stored in an auto-GC-ing table, indexed by the transaction tag
• CRDB: A row is inserted into a metadata table as part of the transaction, which includes the metadata. When seen at the same revision as the other changes, the metadata becomes correlated with that transaction. The rows are set to auto-GC after a period of time in CRDB >= v22

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[josephschorr]

I have read the CLA Document and I hereby sign the CLA

[josephschorr]

recheck

[vroldanbet]

Left a few questions and suggestions, I think the approach makes sense to me. The main concerns are how does this affect write-throughput, but at first glance it shouldn't introduce any new hotspots.

A potential issue here is the overlap with the concept of tuple-level metadata, but we've certainly heard more about this use case than tuple-level metadata. I also do wonder if folks will eventually ask for a transactions API to read these back, but that's an easy thing to do if the time comes.

Finally: I understand these are just the Datastore API changes, but we'd have to make sure there are limits put in place so that folks don't abuse that new field.

[josephschorr]

Updated

[josephschorr]

Rebased

[tstirrat15]

LGTM, see comment