BUG-7901: fix unsynchronized transaction access

BUG-7901: fix unsynchronized transaction access

The evidence in the issue indicates that we have a race condition
where a batch of modifications is being submitted (triggered by
a write/delete and exceeded batch count) and we are observing a
concurrent modification. After auditing the CDS side of this, while
we can improve safety a bit, the scenario has to involve multi-threaded
access by the client.

Looking at TransactionChainManager, it seems to be heavily synchronized,
but there is a hole in the paths which are using getTransactionSafely().

While the access to the TransactionChain, it returns the transaction
(which really is an alias to the wTx field). That throws of static
analysis, as we end up the object pointed to by wTx without holding
the lock -- hence concurrent threads will end up touching the transaction
without any guards, leading to a violation of Transaction contract (which
requires external synchronization).

This patch reworks getTransactionSafely() so it only ensures the field
is initialized as appropriate and makes its callers access the wTx field
with the proper lock held.

Bug: 7500
Bug: 7901
Bug: 8060
Change-Id: I058feb55f91a40ccda6d69ee87cd1a20f792afba
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>