Reevaluate mock testing

[pawanjay176]

In #7505, we used have used the mockall library to create mock objects for helping us test components with unit tests.

Historically, we haven't done this and mainly relied on integration tests to test out beacon_chain components.
The main reason imo is that beacon_chain components are quite tightly coupled and its hard to test out individual components with unit tests.

The integration tests with the BeaconChainHarness are however quite a pain to setup and take significantly longer to run. Mocking the components alleviates some of the setup code and runs significantly faster. It also allows us to have better code coverage in testing.

However, the mocking approach also has some disadvantages too. Some of them I have observed are:

1. The mocking infra can leak into the main code when the code is tightly coupled. For e.g. in Update engine_getBlobsV2 response type and add getBlobsV2 tests #7505 , we had to make a BeaconChainAdapter object to enable the mock testing to work easily
2. It might lead to a little less readable code which is a maintenance burden
3. We might be testing things just for the sake of it when it doesn't materially improve our codebase

This issue is just meant as a placeholder to reevaluate the mocking approach in a couple of months and just check in if it actually improves the codebase.

[dapplion]

I strongly dislike having to taint production code for testing like with the BeaconChainAdapter.

are however quite a pain to setup and take significantly longer to run

Is it that bad?