feat: add unique receipts for cross-subnet transactions

[JDawg287]

Description

This PR resolves the issue with the receiptHash not being unique for two or more cross-subnet transactions.

Problem

Let's try to understand the issue with the following example. For two identical sendToken transactions from the same user on the same subnet, i.e. two transactions where the allowance amount and the arguments for the sendToken transaction are kept the same, we would end up in a situation where the receiptHash would also be identical for these two transactions. This is because there is no nonce for receipts as opposed to transactions where a combination of from and nonce is kept track of to prevent replay attacks. If the two transactions end up in different blocks (let's assume there are no other transactions in both blocks), then the receiptsRoot for both blocks would also be identical.

This isn't a problem on the source subnet, as it is normal to have two blocks with the same receiptsRoot but, it is an issue on the target subnet when we try to execute those transactions. The first transaction would be executed normally but the second transaction would be rejected as it has the same receiptHash as the first transaction. We were using a combination of the receiptsRoot and the receiptHash to identify different transactions.
So, in a nutshell, we need a method to identify these particular transactions uniquely.

Solution

As a solution, we emit an incrementing nonce and the sourceSubnetId as part of the CrossSubnetMessageSent event from the ToposCore contract. This would mean that the receipt data would contain an incrementing nonce for a particular subnet for each sendToken transaction. Since the receipt's trie keeps a record of the receipt's data it would result in a unique receiptsRoot for a block. Furthermore, since the receiptHash is calculated from the receipt's data it would result in a unique receiptHash. As a result, this allows us to uniquely identify different valid transactions with similar arguments.

Fixes TP-864

PR Checklist:

• I have performed a self-review of my code
• I have commented on my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added or updated tests that comprehensively prove my change is effective or that my feature works

[sebastiendan]

I recommend renaming receiptRaw and receiptHash to receiptTrieNodeRaw and receiptTrieNodeHash to avoid future confusion

[dvdplm]

lgtm

[sebastiendan]

@JDawg287 Let's rename the PR to something not ERC20Messaging-specific? (the problem and the fix concern all messaging protocols)

[JDawg287]

@JDawg287 Let's rename the PR to something not ERC20Messaging-specific? (the problem and the fix concern all messaging protocols)

Done

[dvdplm]

@JDawg287 CI is angry. Seems like a legit problem. :/

[JDawg287]

@JDawg287 CI is angry. Seems like a legit problem. :/

We'll have to change the ToposCoreProxy contract address for that. Plus, we also need to adapt the CrossSubnetMessageSent event on the sequencer side. Tasks/PRs were created respectively. Once the they are merged and CI tests are passing we can merge.