refactor: resolve the informer target client without a downcast

[csviri]

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

---

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

• Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
• Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
• Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via Informable#getKubernetesClient().
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default getKubernetesClient() method (now inherited from Informable) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional getKubernetesClient() hook for all informable configurations.