cluster manager: use clusters() instead of get() for main thread cluster validation

[mattklein123]

This is a follow up to #13906. It does a few different things:

1. Renames get() to getThreadLocalCluster() to make it more clear what it does.
2. Adds more functionality to clusters() to make it easier to use for validation.
3. Replaces use of the thread local clusters with the main thread clusters() output for static route
   validation as well as some other places that were using thread local clusters when they should have
   been using main thread clusters during config ingestion.
4. Make mocks default to no main thread clusters and no thread local clusters. Tests using mocks
   have to explicitly opt in to what clusters they want. This makes tests more intentional and less magical,
   but required a bunch of manual fixes. Overall this reduces quite a lot of test debt when using mocks.

This will enable further cleanups in the cluster manager
code.

Risk Level: Low
Testing: Existing tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

[mattklein123]

This is not fully correct. Doing some more invasive work here to clean more stuff up.

/wait

[mattklein123]

This is ready for review. It's mostly mechanical. I can split out the config_impl changes as that is the only real functional change if reviewers prefer.

[mattklein123]

/retest

for OSX. I don't think clang-tidy is going to pass on this one.

[repokitteh-read-only]

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #14204 (comment) was created by @mattklein123.

see: more, trace.

[snowp]

LGTM!

Very happy to see get() renamed, it's definitely been a bit of a gotcha.

[akonradi]

Was ClusterManager::clusters() always unsafe to call on any but the main thread? If not, this seems like a breaking API change that could have caused silent failures.

[mattklein123]

Was ClusterManager::clusters() always unsafe to call on any but the main thread? If not, this seems like a breaking API change that could have caused silent failures.

Yes. This probably should have been better documented and ASSERTed.