Persist useGSN flag for calls to getTransactionReceipt

[spalladino]

After sending a meta tx, the client library (web3) relies on the getTransactionReceipt provider method to check when the meta tx got mined. The GSN specific provider needs to intercept this method to fix the receipt that was sent as a meta-tx.

However, the getTransactionReceipt call does not receive the useGSN flag (since it does not receive parameters). Therefore, when we intercept the getTransactionReceipt call in the GSNProvider, we need to know whether it was a metatx or not.

We can do that by either:

• Keeping a cache of tx hashes sent with useGSN=true, and checking that cache when resolving the transaction receipt.
• Infer whether it was a meta tx given the recipient (it's a relay hub) or the function selector in its data (it's a relayCall). Note that we could get false positives in this case, which would be bad.

[frangio]

Infer whether it was a meta tx given the recipient (it's a relay hub) or the function selector in its data (it's a relayCall). Note that we could get false positives in this case, which would be bad.

If we check both the recipient and the function selector, would there be any false positives? I can't think of any.

If so I would prefer this method over the other one, which can result in false negatives.

[spalladino]

If we check both the recipient and the function selector

Remember that the client does not know the address of the relay hub - it actually queries it from the recipient (the dapp), so this one can be a bit tricky to implement.

[frangio]

Oh, I see. I thought we were using the singleton address.

[nventuro]

This is related to #11: if we store a number of known hub implementations on the client, we can simply use those.

[spalladino]

Fixed in a091c583fc6fd7c0b8b0ad40c24f30b4bfa25897