Upgrade to Camel 4.22.0

[jbonofre]

Upgrades the bundled Apache Camel version from 4.18.1 to 4.22.0 using the tooling/camel-upgrade tool, plus follow-up fixes required by that upgrade:

• Regenerate wrappers/features/catalog for Camel 4.22.0.

• Set the squareup-okhttp-version property (needed by the new Camel version).

• Remove the core/camel-cloud module: Camel 4.22.0 dropped camel-cloud upstream.

• Finish the camel-cloud removal in camel-blueprint: drop the now-unresolvable ServiceCallConfigurationDefinition/ServiceCallDefinition references in CamelContextFactoryBean and BlueprintModelJAXBContextFactory, the stale org.apache.camel.model.cloud OSGi import in camel-xml-jaxb, and the two blueprint tests exercising the removed feature.

• Migrate camel-cxf-blueprint to the CXF 4.2 logging feature: the upgrade also moves CXF from 4.1.7 to 4.2.3, and CXF 4.2 removed the long-deprecated org.apache.cxf.feature.LoggingFeature from cxf-core. Both call sites (the RsServerBlueprintBean field and the <cxf:logging> parser in CXFAPINamespaceHandler) now use org.apache.cxf.ext.logging.LoggingFeature. That class has no LoggingFeature(int) constructor, so the size limit is applied via setLimit(); leaving it unset keeps CXF's own default, matching the previous no-arg behaviour. No new dependency is needed — camel-cxf-all already shades cxf-rt-features-logging, and the camel-cxf feature already installs that bundle ahead of camel-cxf-blueprint.

• Bump camel-osgi-cxf-version from [4.1,4.2) to [4.2,4.3) so the org.apache.cxf.* OSGi imports generated for the four camel-cxf bundles resolve against CXF 4.2 at runtime.

• Fix camel-spring-ai wrapping: Camel 4.22.0 does not publish a single camel-spring-ai jar (the generated wrapper depended on a nonexistent org.apache.camel:camel-spring-ai artifact, which broke the Maven build). Upstream splits it into camel-spring-ai-chat, camel-spring-ai-embeddings, camel-spring-ai-image and camel-spring-ai-vector-store (camel-spring-ai-tools was discontinued after 4.21.0 and merged into chat). Each is now wrapped as its own bundle module under camel-spring-parent, with matching feature entries in camel-features.xml.

• Add org.jspecify:jspecify as a bundle dependency of the camel-core feature: camel-api in 4.22.0 now Import-Packages org.jspecify.annotations (nullability annotations), which broke OSGi resolution for every feature depending on camel-core (caught by the karaf-maven-plugin verify goal in the features module).

• Fix a stale ${jdk-version} property reference in features/pom.xml's karaf-maven-plugin <javase> configuration: the root pom.xml renamed this property to javaVersion in a prior, unrelated change, but features/pom.xml was never updated to match. The unresolved reference silently fell back to a default JDK system-package list missing jdk.jfr, which camel-console now requires in Camel 4.22.0.

• Mark jdk.jfr/jdk.jfr.consumer as optional OSGi imports in camel-console: the ${jdk-version} property fix above was not sufficient on its own — jdk.jfr is a JDK-specific module, not part of the formal JavaSE profile package list karaf-maven-plugin derives from <javase>, so it is still not exported by the system bundle even with the property corrected. Camel 4.22.0's new JfrMemoryLeakDevConsole in camel-console references jdk.jfr/jdk.jfr.consumer, and the module's wildcard camel.osgi.import turned that into a mandatory Import-Package, breaking OSGi resolution for every feature depending on camel-core. Fixed by marking both packages resolution:=optional, matching the existing precedent in camel-core-model/pom.xml for the same package. Verified locally: rebuilding camel-console confirms the manifest now carries jdk.jfr;resolution:=optional (previously mandatory), and re-running the features module's karaf-maven-plugin verify goal confirms camel, camel-core, camel-core+shell and camel-blueprint no longer fail (they were all failing in the CI run against the prior commit).

• Bump jackson2-annotations-version from 2.20 to 2.22: the upgrade bumped jackson2-version from 2.20.1 to 2.22.1 but left jackson2-annotations-version at 2.20 (the correct pairing for the prior 2.20.1) since jackson-annotations doesn't publish patch releases matching jackson-core/jackson-databind's cadence. This was masked by the jdk.jfr failure above (which stopped OSGi resolution before reaching it); once camel-core resolves, features that declare a dependency on the jackson feature (e.g. camel-zookeeper-master, via curator/guava) failed instead, needing com.fasterxml.jackson.annotation >=2.22.0. Verified locally: re-running the features module's karaf-maven-plugin verify goal shows camel-zookeeper-master no longer failing on this requirement.

• Restore 23 third-party version properties in pom.xml that the Camel 4.22.0 upgrade dropped from its wholesale property regeneration but that camel-features.xml still references for wrapped bundles (cglib, xpp3, netty-reactive-streams, vavr, nimbusds content-type/lang-tag/oauth2-oidc-sdk, async-http-client, minidns, checker-qual, neo4j-bolt-connection, parsson, snakeyaml-engine for kubernetes, microprofile-fault-tolerance-api, commons-math3). Each value was verified against the actual Camel 4.22.0 dependency tree (mvn dependency:tree per affected component) rather than restored blindly, so several picked up real version bumps (e.g. minidns-core 0.3.4 → 1.0.5, async-http-client 3.0.3 → 3.0.9, checker-qual 3.53.1 → 3.42.0). The unresolved ${...} placeholders were breaking Karaf feature resolution for camel-xmpp, camel-zendesk, camel-cxf and, transitively, every feature that depends on them.

• Point the docling, langchain4j-hugging-face/langchain4j-community-dashscope and google-auth-library bundles in camel-features.xml at the properties the upgrade's regeneration had already renamed them to (docling-java-version, langchain4j-beta-version, langchain4j-community-version, google-auth-library-oauth2-http-version) instead of the old, now-removed property names.

• Replace the obsolete com.dylibso.chicory bundles in camel-wasm with run.endive, which Camel 4.22.0 now uses for its WASM runtime (confirmed via camel-wasm's actual dependency tree; pom.xml already carried an endive-version property from the regeneration, unused until now).

• Drop the dead reactor-netty-incubator-quic bundle from camel-stitch: QUIC support graduated into Netty core (as already noted by a leftover comment in pom.xml) and is already provided via netty-codec-http3/netty-codec-classes-quic in the same feature.

• Add the missing smack-xmlparser/smack-xmlparser-stax, smack-java8, smack-resolver-javax, smack-sasl-javax and smack-streammanagement bundles to camel-xmpp: smack-core 4.4.8 requires them but they were never declared, a pre-existing gap masked until the minidns/xpp3 placeholders above were fixed and Karaf's resolver could get far enough to see it.

  Verified locally: rebuilding the features module offline confirms 18 features that were failing in CI (camel-docling, camel-elasticsearch, camel-fhir, camel-grpc, camel-kubernetes, camel-langchain4j-chat/embeddings/tokenizer, camel-microprofile-fault-tolerance, camel-neo4j, camel-plc4x, camel-resilience4j/micrometer, camel-stitch, camel-wasm, camel-zendesk, camel-azure-schema-registry, camel-mail-microsoft-oauth) now resolve cleanly, with no new regressions versus the original CI failure set. camel-cxf and camel-xmpp still fail locally, but for separate, pre-existing reasons unrelated to this change (a Karaf-bundled spring feature version mismatch cascading from camel-spring, and a smack-core import on the JDK-internal sun.security.pkcs11 package, respectively) — not addressed here.