StateTransitionRunner refactoring.

[bkolad]

Description

The goal of this PR is to restructure the logic for running the rollup, enabling it to function with various combinations of Runtime/Data-Availability/State-Transition-Function. This modification has several benefits:

1. It makes the logic independent of a particular rollup (currently it is hardcoded in demo-rollup).
2. Simplifies testing (point 1).
3. Facilitates the implementation of in-memory DA.

After this PR, the responsibilities of the relevant components are as follows:

• sov-stf-runner: Abstracts the logic for executing the STF.
• demo-stf: Contains code specific to a particular Runtime, including hooks, configs, and a concrete STFR.
• demo-rollup: Uses both sov-stf-runner and demo-stf, acting as the glue code to initiate the rollup process.

The changes introduced in this PR are as follows:

1. StateTransitionRunner(STFR) is transformed into a concrete type and moved from the rollup-interface to a separate crate full-node/sov-stf-runner. By making it a concrete type, we were able to eliminate DemoAppRunner, NativeAppRunner, and DemoApp, all of which essentially represent the same type beneath the surface. To simplify matters, we removed DaVerifier from the STFR since it was initially included solely for demonstration purposes. However, it can easily be reintroduced if necessary. The logic for running the rollup lives in the run method.

2. We eliminated the RpcRunner trait. As there were no methods or types reliant on this trait, so we didn't really make use of it.

3. All the ledger_XXX rpc methods ware moved to sov-stf-runner because they are common to any kind of rollup.

Future work:

1. Implement MockDA and test sov-stf-runner.
2. The demo-prover/host also has blob processing logic which is similar to the one in STFR, but it simultaneously writes to the host. If we hide the host behind a trait and make it a noop for the node we will be able to extend STFR and use it both in the prover & node
3. The code in sov-stf-runner was mostly copied from demo-stf & demo-rollup and it needs to be cleanup further. For example we have many different Configs with the same name. The code is mostly internal to the crate and don't leak outside.

Linked Issues

• Fixes # (issue, if applicable)
• Related to # (issue)

Testing

Ci passes.

Docs

All related docs to StateTransitionRunner updated.

[codecov]

Codecov Report

Merging #614 (8896c43) into nightly (0635008) will increase coverage by 0.3%.
The diff coverage is 35.3%.

Files Changed	Coverage Δ
full-node/sov-stf-runner/src/batch_builder.rs	99.1% <ø> (ø)
full-node/sov-stf-runner/src/config.rs	100.0% <ø> (ø)
full-node/sov-stf-runner/src/lib.rs	0.0% <0.0%> (ø)
full-node/sov-stf-runner/src/runner_config.rs	100.0% <ø> (ø)
module-system/sov-modules-api/src/lib.rs	82.3% <ø> (ø)
...ystem/sov-modules-stf-template/src/app_template.rs	82.7% <ø> (ø)
module-system/sov-modules-stf-template/src/lib.rs	84.2% <ø> (ø)
full-node/sov-stf-runner/src/ledger_rpc.rs	93.0% <93.0%> (ø)

... and 1 file with indirect coverage changes

[citizen-stig]

@bkolad, does design in this PR accommodates running a prover? Or is it only for a full node?

[bkolad]

2. The demo-prover/host also has blob processing logic which is similar to the one in STFR, but it simultaneously writes to the host. If we hide the host behind a trait and make it a noop for the node we will be able to extend STFR and use it both in the prover & node

Future work:
"The demo-prover/host also has blob processing logic which is similar to the one in STFR, but it simultaneously writes to the host. If we hide the host behind a trait and make it a noop for the node we will be able to extend STFR and use it both in the prover & node"

[preston-evans98]

Looks amazing overall. Just two small things!