feat(runner): Refactor Extension Configs #269
Description
Background
In #268, the BaseNodeRunner is refactored to allow for generic extensions. These are strongly typed instances of the BaseNodeExtension trait that removes the ad-hoc extensions installation contained inside the BaseNodeRunner. Instead, extension installation is hoisted to the binary entrypoint to allow the node to be configured programmatically. By using explicit extension installation at the consumer level, the node becomes more configurable and avoids silent, unknown extension behavior.
Tangentially, #268 moves the FlashblocksCell into the BaseNodeConfig. Previously, it had been instantiated and passed into both the FlasblocksCanonExtension and the BaseRpcExtension through the constructor method. No longer. The FlashblocksCell is now placed in the BaseNodeConfig. Since the BaseNodeExtension creates the extension using the BaseNodeConfig, the extension constructor can just clone that OnceCell from the BaseNodeConfig.
Description
Note
TL;DR Background: #268 made extensions generic, moving the FlashblocksCell type into the config so it can be cloned when constructing the FlasblocksCanonExtension and BaseRpcExtension extensions.
This issue is to figure out how to make this approach more extensible. As new extensions are added in the future, we want to avoid type stuffing, where the BaseNodeConfig continuously grows.
One option is to just generic parameters - T::Config - for the extension install. That is, the config type is defined by the extension and the install method looks like: runner.install_ext::<T>(T::Config)?;. This way, the consumer (node builder) is forced to instantiate the FlashblocksCell and then pass it in as a parameter to the extensions that require it. The downside to this approach is expanding the node entrypoint - main.rs needs to perform this extension install argument wiring as they increase in complexity.