[docdb] Release locks acquired during aborted subtransaction

[robertsami]

Jira Link: DB-524
During a normal (no explicit locks) serializable read, we transparently write an "implicit" kStrongRead intent lock. These locks always belong to the top-level transaction (see: #9587)

However, in all other cases, including serializable reads with explicit locks, we should treat these locks as part of the subtransaction, and therefore they should be ignored by or invisible to other transactions if they are aborted (see: https://github.com/postgres/postgres/blob/master/src/backend/access/heap/README.tuplock#L99).

As a first cut, perhaps we can do this in a "best effort" async manner.

However, in order to fully match the behavior of Postgres, we should release these locks synchronously. Not doing so could lead to the following behavior, which does not match Postgres:

process 1

-- client 1

-- client 2

client 1 - begin;
	 - savepoint a;
	 - select * from t where a = 1 for update;

client 2 - begin;

client 1 - rollback to a;

client 2 - update t set b = 2 where a = 1 for update;  # if above rollback was not effectively synchronous, we may still conflict here

We could make this operation effectively synchronous by making ROLLBACK TO {savepoint} synchronously talk to the transaction coordinator and making some other modifications to our write path when determining if a lock belonging to a subtransaction_id > 1 is still valid.