Notary request tracking is incorrect

[roman-khimov]

Expected Behavior

Notary requests should be tracked by their actions and main transaction hash.

Current Behavior

Looking at signatures to determine if it's a new notary request to handle is just plain wrong (see notary preparator code in #2310).

Possible Solution

Rework this mechanism to improve reliability.

[roman-khimov]

Related to #678, btw.

[carpawell]

@roman-khimov, @AnnaShaleva, I have done some scientific research and now I think the issue is about that thread, right?

So I would like to sync some questions:

1. Basically that is not "request tracking is incorrect" but it is just missing at all, right? We do not track notary requests and just consider every signed request as an already handled one. What is the problem here? How can it be exploited?

Rework this mechanism to improve reliability.

2. I think that is about sending notary requests and storing their hashes (btw, in-mem? persistently?)? If a notary request is sent by a node, it can store TX's hash and... can be able to do what? Send the same one if a fallback is on the chain? Or that is about Monitor fallback transactions in WSClient #678? What that issue is about? Just about skipping self-created notary requests?

Notary requests should be tracked by their actions and main transaction hash.

3. What does "by their actions" mean here?

[roman-khimov]

1. We're signing whatever request comes in. Suppose I'm a mad IR node sending epoch updates every block, everyone will sign them happily. It's not good.
2. Fallback tracking is a different thing. Related, but different. It's about tracking failures and trying again when there is a need to (again, think about epoch updates).
3. Epoch update from X to Y -> tx A.