Fix for #6296: Deterministic RNG in peer DAS publish block tests

[SunnysidedJ]

Issue Addressed

#6296: Deterministic RNG in peer DAS publish block tests

Proposed Changes

Made test functions to call publish-block APIs with true for the deterministic RNG boolean parameter while production code with false. This will deterministically shuffle columns for unit tests under broadcast_validation_tests.rs.

Additional Info

1. Tested with "cargo test --workspace --release --features "$(TEST_FEATURES)" --exclude ef_tests --exclude beacon_chain --exclude slasher --exclude network --exclude web3signer_tests" which is same as "make test" but excluding web3signer_tests. The suggestion from the Lighthouse Book, update JDK/JRE to the latest (17 or above and I used 24), did not work. Please let me know if this is okay.
2. Tests related to the issue (bn_http_api_tests) was disabled by default. I manually enabled to run tests calling related API changes. See beacon_node/http_api/tests/main.rs. Many functions here result in stack overflow for some reason on my local machine.
3. Please clarify intention and scope of changes. I merely took the word-by-word on the issue Deterministic RNG in peer DAS publish block tests #6296 by changing existing test code to take a fixed seed. Do you want to make it more customisable or use different design? Also, it'd be appreciated to know the intention of changing it to something deterministic. How does it affect testability, and what kinds of testing can we do further?

[CLAassistant]

All committers have signed the CLA.

[michaelsproul]

I don't really love adding a random bool parameter here. I wonder if a cleaner approach would be to add an rng: Arc<RwLock<Box<dyn RngCore>>> field to BeaconChain which is initialised either as the thread_rng or a seeded RNG depending on config? The BeaconChainHarness could initialise it in seeded mode, while the BeaconChainBuilder used in production could initialise it as thread_rng.

What do you think @SunnysidedJ?

[SunnysidedJ]

Thank you for making this comment with detailed pointers. I was also wondering a good place to pass RNG instances instead, but I wasn't able to due to my lack of knowledge in the codebase and Rust (I'm a beginner). One thing that I couldn't use was ThreadRng instance for production code because it is a thread-local object which cannot be passed between threads. Would a slight degrading of performance due to the use of OsRng be a concern for you? The logic otherwise seems the same according to its documentation. Nonetheless, I hope the new change is something closer to what you expect!