add completedTransaction as a subscription

[eauge]

Implement a completedTransaction that can handle transactions from confidential contracts

[coveralls]

Coverage increased (+0.7%) to 81.649% when pulling 41f21c4bed05bb07b33009c6477beb9cee1c17e8 on eauge/subscribe/add-completed-transaction into e45d86a5b9bbbe910c39bc277da8f841403d9818 on master.

[armaniferrante]

To summarize offline conversations, we need an answer to the following question: can we guarantee that the web3c.js client has access to a transaction hash prior to actually sending it off to the gateway?

If the answer is yes, then this approach is swell. If the answer is no, then we might have a problem.

Imagine the following situation

• Client sends transaction through provider (e.g., metamask).
• The provider, e.g. metamask or hdwalletprovider signs the transaction, and then sends it simultaneously to the gateway and back to the web3c.js client.
• At this point the web3c.js client subscribes to the gateway waiting for the transaction to be completed. But now we have a race condition. There might not be a guarantee the subscription happens before the transaction is complete.

If this is indeed a problem, then the implementation needs to support the case where the subscription happens after the transaction is sent.

If we're using a websocket connection, one way around this is to subscribe to all transactions from a given address. Send the transaction through the exact same websocket connection, and then receive the response. This works because we're connected to the same gateway instance. If we can't guarantee that we're connected to the same gateway instance, the return value is not retrieved by the gateway that didn't initiate the transaction.

A more complicated solution would be to somehow store and allow the gateway to fetch the return value. This seems like the most immediate solution if we use storage.

@eauge @willscott @peterjgilbert thoughts here?

[eauge]

@armaniferrante good summary.

I would suggest to try to find a way to access the transactionHash of a transaction before sending it. If that's not possible, I would do the trick of subscribing to transactions for a fromAddress.

I would avoid including storage to this unless strictly necessary. Then there would be all sorts of other problems.