fatxpool: do not use individual transaction listeners

[michalkucharczyk]

Description

During 2s block investigation it turned out that ForkAwareTxPool::register_listeners call takes significant amount of time.

register_listeners: at HashAndNumber { number: 12, hash: 0xe9a1...0b1d2 } took 200.041933ms
register_listeners: at HashAndNumber { number: 13, hash: 0x5eb8...a87c6 } took 264.487414ms
register_listeners: at HashAndNumber { number: 14, hash: 0x30cb...2e6ec } took 340.525566ms
register_listeners: at HashAndNumber { number: 15, hash: 0x0450...4f05c } took 405.686659ms
register_listeners: at HashAndNumber { number: 16, hash: 0xfa6f...16c20 } took 477.977836ms
register_listeners: at HashAndNumber { number: 17, hash: 0x5474...5d0c1 } took 483.046029ms
register_listeners: at HashAndNumber { number: 18, hash: 0x3ca5...37b78 } took 482.715468ms
register_listeners: at HashAndNumber { number: 19, hash: 0xbfcc...df254 } took 484.206999ms
register_listeners: at HashAndNumber { number: 20, hash: 0xd748...7f027 } took 414.635236ms
register_listeners: at HashAndNumber { number: 21, hash: 0x2baa...f66b5 } took 418.015897ms
register_listeners: at HashAndNumber { number: 22, hash: 0x5f1d...282b5 } took 423.342397ms
register_listeners: at HashAndNumber { number: 23, hash: 0x7a18...f2d03 } took 472.742939ms
register_listeners: at HashAndNumber { number: 24, hash: 0xc381...3fd07 } took 489.625557ms

This PR implements the idea outlined in #7071. Instead of having a separate listener for every transaction in each view, we now use a single stream of aggregated events per view, with each stream providing events for all transactions in that view. Each event is represented as a tuple: (transaction-hash, transaction-status). This significantly reduce the time required for maintain.

Review Notes

• single aggregated stream, provided by the individual view delivers events in form of (transaction-hash, transaction-status),
• MultiViewListener now has a task. This task is responsible for:
  • polling the stream map (which consists of individual view's aggregated streams) and the controller_receiver which provides side-channel commands (like AddView or FinalizeTransaction) sent from the transaction pool.
  • dispatching individual transaction statuses and control commands into the external (created via API, e.g. over RPC) listeners of individual transactions,
• external listener is responsible for status handling logic (e.g. deduplication of events, or ignoring some of them) and triggering statuses to external world (this was not changed).

Todo

• Add better description, prdoc, etc...
• Review mod doc, and update it
• one test seems to be flaky (rarely fails).
• maybe also address fatxpool: improve event listeners #5495 🤔 ?

Closes #7071