HOTFIX: Fix null pointer when getting metric value in MetricsReporter

[PhilHardwick]

The alive stream threads metric relies on the threads field as a monitor object for
its synchronized block. When the alive stream threads metric is registered it isn't
initialised so any call to get the metric value before it is initialised will result
in a null pointer exception.

This is tested in a minimal integration test where the KafkaStreams object is created
but not started and the test loops through all metric values to check they're not null.

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)

[PhilHardwick]

Requesting review from @ableegoldman and @wcarlson5 please

[wcarlson5]

This seems like a reasonable fix

[ableegoldman]

LGTM, thanks for the fix!

[ableegoldman]

Merged to trunk and cherrypicked to 2.8

[kkonstantine]

Approved for 3.0 as well.

[ableegoldman]

Cherrypicked to 3.0

[jolshan]

Hi. This PR seemed to break the 2.8 branch. When I try to run checkstyle I see:

> Task :streams:compileTestJava
/Users/jolshan/kafka/streams/src/test/java/org/apache/kafka/streams/integration/MetricsReporterIntegrationTest.java:73: error: stop() has private access in EmbeddedKafkaCluster
        CLUSTER.stop();

I believe that file was added in this commit.

[ableegoldman]

@jolshan ah, whoops. Thanks for the heads up. I'll get a patch ready

[ableegoldman]

Fix is available here: #11257

This also got me digging into why we had to make stop() public in 3.0, and seem to now be required to manually invoke both start() and stop() in every single integration test...which is incredibly error prone (or rather, resource-leakage prone). I fixed the 2.8 build in a way that should prevent future backports from breaking the 2.8 branch specifically, but I'm going to look into just improving how we do this in 3.0+ so we don't need to worry about breaking older branches than 2.8, or leaking resources by forgetting to clean up this cluster... 😬

Anyways, thanks very much for bringing this up!