[hotfix] Reuse FlinkConfigManager#isSnapshotCrdInstalled in controllers

[Dennis-Mircea]

What is the purpose of the change

FlinkConfigManager already discovers whether the FlinkStateSnapshot CRD is installed at operator startup (via the boolean it accepts from FlinkOperator) and stores the result in a final field. Despite that, both FlinkDeploymentController and FlinkSessionJobController were calling KubernetesClientUtils.isCrdInstalled(FlinkStateSnapshot.class) again from their prepareEventSources methods. That helper does not just hit the API server, it also constructs a brand-new KubernetesClient (new KubernetesClientBuilder().build()) with its own TLS handshake and auth chain, then issues a list().getItems() call. The result is three independent API roundtrips and three transient clients to answer the same question whose answer is already cached on FlinkConfigManager.

This PR exposes that flag through a getter and switches both controllers to use it.

Brief change log

• Added FlinkConfigManager#isSnapshotCrdInstalled() (plain Java getter, no Lombok) returning the existing snapshotCrdInstalled field.
• Replaced KubernetesClientUtils.isCrdInstalled(FlinkStateSnapshot.class) with flinkConfigManager.isSnapshotCrdInstalled() in FlinkDeploymentController#prepareEventSources and FlinkSessionJobController#prepareEventSources.
• Removed the now-unused imports KubernetesClientUtils and FlinkStateSnapshot from both controllers.
• Added a FlinkConfigManager field + constructor parameter on FlinkSessionJobController (it did not have one before). Updated FlinkOperator#registerSessionJobController and TestingFlinkSessionJobController to pass it in.
• While in FlinkDeploymentController, specialized two method signatures from raw Context to Context<FlinkDeployment> (cleanup and reconcile), resolving raw-type warnings the IDE was flagging in the file we were already editing.

Verifying this change

This change is already covered by existing tests, such as FlinkDeploymentControllerTest, FlinkSessionJobControllerTest, FlinkStateSnapshotControllerTest, FlinkConfigManagerTest, and FlinkOperatorTest.

Behavioral equivalence: prepareEventSources is invoked once at JOSDK controller registration. The snapshotCrdInstalled flag is computed once at FlinkOperator construction (right before FlinkConfigManager is built). Both points happen during operator startup with no possibility of the CRD state changing between them, so the answer used by both controllers is identical to today's behavior. The only difference is that we no longer build two transient KubernetesClient instances and issue two extra list() calls.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changes to the CustomResourceDescriptors: no
• Core observer or reconciler logic that is regularly executed: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable