Don't lock EpochManager across the system

[ilblackdragon]

Currently we are locking EpochManager across the client and view client. We are locking it because it's maintained under RuntimeAdapter which is shared between Client and ViewClient.

There is alternative (a) that @SkidanovAlex suggested:

• Remove EpochManager from RuntimeAdapter and provide clones of it directly to Client and ViewClient. This will mean caches will be separate and wouldn't require locks.

We had reasoning why we didn't want to move EpochManager from RuntimeAdapter, and it was because we at some point wanted to move it's logic inside the Runtime as a smart contract.

Another alternative, is that redesign EpochManager in a way that Chain maintains it's own information that it needs. This would be in a way similar to previous suggestion, where Chain / Client have a data structure of the fields they need to maintain current validators public keys & related info. EpochManager moves into Runtime, and becomes only collecting proposals and runtime just returns after some state transition new set of validating public keys (and related info). This would also be closer to what this was initially planned.

[bowenwang1996]

@ilblackdragon I assume this is needed for phase 1. Let's not redesign EpochManager and just apply the bandaid solution that Alex suggested.

[ilblackdragon]

I think before we do anything like this - I want to have a benchmark we can run that clearly shows performance and bottlenecks. Right now we have only hypotheses. Given we only just right now noticing that everything was running on single core.

[bowenwang1996]

@ilblackdragon agree

[damons]

Moving to Phase 2 per Phase 1 triage.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[matklad]

was closed by #6549