Proper implementation of `authenticate` transactions processing during TxPool validation

[dmitrylavrenov]

The task has been created as follow up #41.

If we exclude nonces and replay attack defense logic, we can technically merge existing active authentication and a newly incoming authentication - so we can effectively get a CRDT semantics. But we should properly process authenticate transactions during TxPool validation to reduce a blockchain network load and prevent spoofing. In other words, a user won't be able to submit a lot of authenticate transactions if his current authenticate transaction is still valid. Nodes don't need to do extra activities by validating and importing them into block.

A new one authentication can be accepted before, for example, 2 hours. It should be discussed.

[MOZGIII]

To resolve this further, we'd need to review the tx path from the RPC to the TxPool and inspect what validations are conducted.

There are ultimately two things we want to take care here:

1. that the blocks are not flooded with the authenticate txs spam
2. that the gossip and txpools are not flooded with txs

The defense against both should be achievable via custom SignedExtention, which we already do; we have a validate_unsigned fn that is involved at the inclusion of the tx into txpool, and the pre_dispatch_unsigned fn that is checked before the tx gets applied when included in the block.