Revert "Thread manager instantiation in the validator (#4603)"

[steviez]

This reverts commit e48672c.

Problem

It isn't clear if the thread manager is the way we want to go long term. We should get consensus amongst the team / testing / data that shows benefit (including worst case scenarios) before instantiating the object in production. At the present, we spin up 24 extra threads that are unused as far as I am aware.

Summary of Changes

This reverts the commit that create a ThreadManager in Validator; the code remains but unused by agave-validator

[alexpyattaev]

@steviez the plan was to start adding workload to it but that got blocked. Thanks for bringing this up!
@t-nelson you had strong objections to thread manager initiative, please comment how you want us to address the zoo of runtimes spawned all over agave? Specifically, should we organize the ownership in some systematic way or keep using lazy_static?

[bw-solana]

@alessandrod should be part of the design discussion as well

[t-nelson]

let's not pollute this pr with the discussion

#5142

[steviez]

the plan was to start adding workload to it but that got blocked. Thanks for bringing this up!

Couldn't this testing be done before we merged #4603 ? Ie, keep a branch and test / collect data / etc, and then merge the instantiation of ThreadManager + use of ThreadManager (if we end up going that route) together, either as same PR or as PR's in quick succession where one is contingent on the other.

As-is, master and the v2.2 branch currently instantiate a ThreadManager with the 24 threads that are unused. This is wrong IMO, hence my PR to revert (with intent to BP this to v2.2 as well)

@alessandrod should be part of the design discussion as well
let's not pollute this pr with the discussion

To be clear, this PR isn't me saying "we're not doing ThreadManager". Rather, this is me saying "let's continue discussion & data collection on ThreadManager before creating this object in the validator"

[t-nelson]

is there any merit to retaining the dead code? should we happen to decide that this is in fact the way to go, we can recover everything from history

[steviez]

is there any merit to retaining the dead code? should we happen to decide that this is in fact the way to go, we can recover everything from history

That code was added in #3890 so we'd seemingly revert that (and #4692) separately. I have less strong opinions about this aspect but I agree that we could recover this from history (revert the revert commit 😆)

[t-nelson]

is there any merit to retaining the dead code? should we happen to decide that this is in fact the way to go, we can recover everything from history

That code was added in #3890 so we'd seemingly revert that (and #4692) separately. I have less strong opinions about this aspect but I agree that we could recover this from history (revert the revert commit 😆)

my vote would be to unwind the stack if this one goes

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.