Do not block pool processing on rebroadcast

[georgeee]

Problem: in certain conditions processing of a pool item may stall block processing. This happens because transition frontier extension event is written to a synchronous pipe which is read from the merged reader of a few items:

Strict_pipe.Reader.Merge.iter_sync
             [ Strict_pipe.Reader.map tf_diffs ~f:(fun diff ->
                   Transition_frontier_extension diff )
             ; remote_r
             ; local_r
             ]

Despite remote and local pool items being given a lower priority, processing of them may block transition frontier extension handling. It leads to a significant (multiple seconds) delay on one block, but also leads to accumulation of unprocessed blocks. If the delay repeats a few times (which is probabilistic), block delay may start growing as an avalanche, leading to hundreds of seconds of delays in block processing.

Explain your changes:

• Wrap broadcasting of a pool item into don't_wait_for

Explain how you tested your changes:

• Tested on a private cluster

PR is built on top of #13550 because that contains Remove snark tables lock change which significantly simplifies pool processing code and makes implementation of this PR easier.

Checklist:

• Dependency versions are unchanged
  • Notify Velocity team if dependencies must change in CI
• Modified the current draft of release notes with details on what is completed or incomplete within this project
• Document code purpose, how to use it
  • Mention expected invariants, implicit constraints
• Tests were added for the new behavior
  • Document test purpose, significance of failures
  • Test names should reflect their purpose
• All tests pass (CI will check this if you didn't)
• Serialized types are in stable-versioned modules
• Does this close issues?

[nholland94]

!ci-build-me