SRI Integration Test: Message Synchronization Primitives

[plebhash]

The third stage of #1120, blocked by #1093 + #1119

Consists of the following goals:

• Ability to declare specific SV2 messages and turn them into frames.
• Ability to assert some tested role is receiving some specific message/frame at some specific stage of the test execution flow.
• Ability to assert some tested role is sending some specific message/frame at some specific stage of the test execution flow.
• Ability to mock roles. We must be able to easily deploy a TCP socket that is able to act as a server/upstream (by listening for connections), or as a client/downstream (by attempting connections) while injecting specific messages/frames at some specific stage of the test execution flow.

---

As a starting point, the following integration test could be used to drive initial development of these message synchronization primitives:

1. Start a regtest TP process (with 16 premined blocks).
2. Start a Pool that connects to TP.
3. Assert that Pool sends a SetupConnection with flag 2 (Template Distribution Protocol) to TP.
4. Assert that Pool receives a SetupConnection.Success with flag 2 back from TP.
5. Assert that Pool sends a CoinbaseOutputDataSize to TP.
6. Start a mock for a Downstream Proxy(JDC/MiningProxy) that connects to Pool.
7. Mock Proxy sends a SetupConnection with flag 0 (Mining Protocol) to Pool.
8. Assert that Pool sends a SetupConnection.Success with flag 0 back to Mock Proxy.

Please note that step 4 is asserting Pool received a message, but it is not asserting that TP sent a message. This framework cannot have access to the TP internal behavior, since it is just a bitcoind process operating in regtest mode.

In order to internally assert TP behavior, more extensive work will be required. While maybe desirable, this work should for some future scope and is not relevant right now, mainly due to the complexity that cross-language barriers (Rust vs C++) will introduce.

---

The following resources can be used as references for inspiration on coding patterns:

• network_helpers_sv2
• demand-easy-sv2
• coinbase-monitor
• demand-test-data-collector

---

• PoolSv2 integration tests #1066
• Invistigate integration tests current-thread runtime overloading #1167

[plebhash]

• Ability to mock roles. We must be able to easily deploy a TCP socket that is able to act as a server/upstream (by listening for connections), or as a client/downstream (by attempting connections) while injecting specific messages/frames at some specific stage of the test execution flow.

this goal was disputed by @jbesraa and requires further discussion