Simplify ProtocolContext and ConsensusContext creation

[fab-10]

PR description

Built on top of #7791, #7862 and #7863

There are no functional changes in this PR, since it is refactor only. The goal is to simplify the ProtocolContext creation,
Moreover the ConsensusContext is now created before the ProtocolContext, removing the need of the factory.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[daniellehrner]

@fab-10 Could we use a builder pattern instead? createPartiallyInitialized improves the readability, but I still don't know which parts are initialized and which are still missing.

The builder could hide the multi step creation from the user.

[fab-10]

@fab-10 Could we use a builder pattern instead? createPartiallyInitialized improves the readability, but I still don't know which parts are initialized and which are still missing.

The builder could hide the multi step creation from the user.

I thought about it, but in this case it is not possible since ProtocolContext is being used, before it is completely set, to create what it is missing, the synchronizer, so in order to use a builder we should make the objects that are needed to create the synchronizer use the ProtocolContext.Builder but it does not seem a good idea.
Maybe at the end the synchronizer should not be in the ProtocolContext at all, to break this circular dependency, will check what implies removing the synchronizer from the ProtocolContext

[garyschulte]

Looks like a good tradeoff to get rid of the cyclic dependency

[garyschulte]

👍

another option could be to seal the context as part of setting the synchronizer. One less step to 'forget' for future implementers.

[fab-10]

thanks @garyschulte for reviewing, but this part has been superseded by this new PR #7862 to remove the synchronizer from ProtocolContext

[fab-10]

@daniellehrner @garyschulte please take another look, the PR has changed from the first version, since with the previous PRs there is more the need to create a partially initialized ProtocolContext and it can just be immutable.