Refactor tests

As noted in PR #571, our usage of mocks in testing is somewhat brittle.

We should do a pass over all tests and ensure that we are actually testing the unit we think we are.

As an example, a lot of the block witness/prover tests [here](https://github.com/0xPolygonMiden/miden-node/blame/0f6b69af58189755d0ec9b13f994d3ef75317485/crates/block-producer/src/block_builder/prover/tests.rs#L813) are actually testing test setup code that is not directly used by production code.

Mocks (in this context) are generally used to represent things that are painful to instantiate or setup e.g. database or a network connection. However usually in the long run these mocks quickly drift apart from the real thing. An indicator that we're doing the wrong thing is if we transform something into a trait purely so we can mock it during tests. This should be the last resort and must be strongly motivated (imo).

Some (better) alternatives:
- Improve the underlying type by creating builders or making it easy to generate realistic input data. This is often the root friction causing us to reach for abstractable traits. Being able to actually generate real data trivially will pay dividends in the long run.
- Separate the input source from the functionality you want to test. Separate of `fn(InputSource) -> Output` into `fn(InputSource) -> Input` and `fn(Input) -> Output`. The latter is usually much easier to test and generate input data for.