overhauling all threading concerns related to informers

[shawkins]

Description

Fix for #3072 and #3143, which includes:

• fully removing the controller thread and making run blocking - this could be viewed as an important behavioral change. This requires not using the forkJoin pool in the informer factory because the async run calls will be blocking. However this allows anyone directly calling run to know immediately if the informer has been established without using a listener. An alternative is to add a separate runBlocking method and go back to passing in the executorservice into the DefaultSharedIndexInformer. Note the go implementation has a blocking run method - https://github.com/kubernetes/client-go/blob/f6ce18ae578c8cca64d14ab9687824d9e1305a67/tools/cache/controller.go#L127 https://github.com/kubernetes/client-go/blob/f6ce18ae578c8cca64d14ab9687824d9e1305a67/tools/cache/shared_informer.go#L157

• made all thread pools daemon - by using a utility method
  to create the daemon thread factory

• inverting the paradigm for processorlistener execution

• merging the controller class with defaultsharedindexinformer, since controller only had a minimal amount of responsibilities

• since resync is in-memory only there is now only 1 shared scheduler for all informers, which is also reused by abstractwatchmanager

• event handlers are processed in a thread off of main informer threadpool - but retain serial execution.

• to remove the code smell of the run exception handling, SharedInformerEventListener should provide the informer #3143 was addressed by moving concerns about the informer listerners to the factory.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[centos-ci]

Can one of the admins verify this patch?

[shawkins]

If the approaches here seem good, then logic in dsl.internal would be good to review for consolidating threading concerns.

[manusa]

Relates to: #2010

[shawkins]

I've expanded the scope to include the the AbstractWatchManager thread as well - it will now use shared resources, rather than a dedicated thread. The only dedicated threads now related to informers will be held by okhttp.

All of the resync related changes are potentially moot based upon #3159

[manusa]

LGTM, thx!

[sonarcloud]

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities
0 Security Hotspots
7 Code Smells

59.3% Coverage
0.0% Duplication