feat: new transaction feature branch

[danieljbruce]

Summary

This PR ensures that transaction read calls will use newTransaction options to begin transactions instead of making a separate beginTransaction grpc call.

Source code changes

A #blockWithMutex function is added and it is used for read calls instead of a #withBeginTransaction function. This makes it so that all read calls on Transaction will block on the mutex and then call the same method in their super class. Before this change, the read calls on Transaction would block on the mutex, make a beginTransaction grpc call and then call the same method in their super class. So this change to using #blockWithMutex omits the extra beginTransaction call and instead expects the function it is calling to supply new transaction options.

A function getTransactionRequest is added which pulls out the code used for building transaction options for a beginTransaction request. That is because this code is also used to build the new transaction options.

TransactionState is moved up to the super class DatastoreRequest and a new state is added called NOT_TRANSACTION for DataRequests that are not transactions.

parseTransactionResponse is moved up to the super class DatastoreRequest and is now used by runQuery, runAggregationQuery and get to save the transaction id.

newTransaction options are now built in getRequestOptions which is used by runQuery, runAggregationQuery and get to save the transaction id.

state is moved up to the DatastoreRequest super class because it now has to be used to decide whether or not to build newTransaction options.

If a transaction is expired then an error will be thrown when the transaction is used.

ReadOptions are the options shared by Datastore read requests. new_transaction is a consistency type in ReadOptions. When new_transaction is used in a read request, a new transaction is begun for the request.

System tests added

A system test is added to ensure using new transaction has better latency. System tests are added for runQuery, runAggregationQuery and get for readOnly transactions to ensure readOnly transactions work correctly whether transaction.run is called or not.

Unit tests added

Unit tests are added for various orders of transaction operations that ensure correct behaviour for when transaction.run is used and when transaction.run is omitted. lookup, lookup, put, commit is one order that is tested. The others are runQuery, lookup, put, commit, runAggregationQuery, lookup, put, commit, put, put, lookup, commit and put, commit. A unit test is also corrected.

Drawbacks

If the user uses transaction.runQueryStream or they use transaction.createReadStream then the call will not block on a mutex. These methods are not async methods so they cannot wait for a #blockWithMutex call to complete. If users are currently using runQueryStream or createReadStream concurrently then these multiple read calls may be beginning multiple transactions at the same time using one transaction object which is not ideal.