1649: Disable the on-demand start of mini-protocol threads for now r=dcoutts a=dcoutts
Fixes issue #1646.
This is an alternative to #1648. This PR simply disables on-demand start. That PR tries to fix it. However this bit of code is in the middle of being refactored so it is simpler to disable it for now and include the fix in the refactoring.
The problem, we realised, is that which peer initiates the overall mux bearer is actually independent from whether protocol threads should be started on-demand or started eagerly. What it really depends on is which peer has agency in the initial protocol state. For most mini-protocols it is the peer that initiated the bearer that has agency in the initial state, but that is not true for all protocols, and in particular for the TxSubmission protocol in ouroboros-network.
The solution will be to make the on-demand vs eager distinction independent of the initiator vs responder distinction, and have it be specified in the MuxMiniProtocol.
We missed this in the network-mux and ouroboros-network tests because we did not have bundles of mini-protocols with mixed initial agency. This should be corrected.
Co-authored-by: Duncan Coutts [email protected]