[DO NOT MERGE] Add opt-in Jackson 3 support via multi-release JAR

[cretz]

What was changed

• Added Jackson3JsonPayloadConverter as a multi-release JAR entry (Java 8 stub in src/main/java/, real implementation in src/main/java17/) that uses Jackson 3.x JsonMapper for JSON serialization
• Added JacksonJsonPayloadConverter.setDefaultAsJackson3(boolean, boolean) static method to globally opt in to Jackson 3 delegation, including for the default converter in DefaultDataConverter.STANDARD_PAYLOAD_CONVERTERS
• Jackson 3 converter supports two modes: native Jackson 3 defaults (jackson2Compat=false) and Jackson 2 compatibility mode (jackson2Compat=true via JsonMapper.builderWithJackson2Defaults())
• Converters with an explicit ObjectMapper passed to the constructor are not affected by the global Jackson 3 delegate
• Both converters produce identical "json/plain" encoding type and are wire-compatible in both directions
• Jackson 3 is published as an optional dependency with version range [3.0.4,) in the POM
• Added jackson3Tests test suite (8 tests, Java 17 launcher) covering direct converter usage, wire compatibility, global delegation via GlobalDataConverter.get(), and explicit-mapper opt-out
• Added Jackson-3-absent tests to the main test suite verifying correct error behavior on Java 8 (UnsupportedOperationException) and Java 17+ without Jackson 3 (NoClassDefFoundError)
• Added jackson3Tests CI step to the unit_test_jdk8 job
• Added @Documented to the @Experimental annotation

DO NOT MERGE - we are going to wait on Spring Boot 4 support at the same time to at least get reviewed at #2786

Checklist

1. Closes Jackson 3 support #2746

[Quinn-With-Two-Ns]

What about the SDK's internal uses of jackson like for Nexus?

[cretz]

What about the SDK's internal uses of jackson like for Nexus?

Can you clarify which internal uses? If it's JSON in and JSON out from server POV, the user doesn't care what JSON serialization we use internally (e.g. for search attributes), and we should continue to use the dependency that is always present (which is Jackson 2 for now).

[Quinn-With-Two-Ns]

So to be clear this PR doesn't let users opt out of including Jackson 2. It just lets them include Jackson 2 and Jackson 3?

[cretz]

It lets users opt-out of using Jackson 2, but not opt-out of the dependency. We have never allowed opting out of the Jackson 2 dependency, and I am worried what it'd take to make it an optional dependency without breaking users today. If there is a good option here of being able to opt-out of the Jackson 2 dependency, I think we can discuss them, but I think leaving the required dependency as we always have should be harmless.

[anatoliy-pylypchuk-kg]

@cretz I think that Temporal SDK should not force users to have Jackson 2 on the classpath/modulepath if Jackson 3 is available. This may be problematic - for example, Hibernate will add support for Jackson 3 in version 7.3 but by default, if both Jackson versions are available, it will choose Jackson 2 (this can be overridden of course, but the point still stands I believe). Having Jackson 2 still available implicitly may have similar consequences in other places as well and they would be difficult to debug if inconsistencies in JSON (de)serialization are found because of that.

Of course, having Jackson 3 support while still requiring Jackson 2 internally is better than no support for Jackson 3 at all, so if it would take a lot of effort to refactor this requirement out, then I think this PR could be merged as-is. But I strongly believe that the Jackson 2 requirement should be lifted in the future.

[cretz]

I think that Temporal SDK should not force users to have Jackson 2 on the classpath/modulepath if Jackson 3 is available

We already require this today even if you have/use Jackson 3 available. We have extreme backwards compatibility requirements for this repository, so coordinating the removal of a dependency users expect and that we use internally is non-trivial and is a breaking change that has to be planned with at least a deprecation first.

if it would take a lot of effort to refactor this requirement out, then I think this PR could be merged as-is. But I strongly believe that the Jackson 2 requirement should be lifted in the future.

This is definitely the case, and we use Jackson 2 things internally and people have expectations built around its behavior and its implicit presence. We can't go just yanking a transitive dependency people may rely on just because we are adding this PR. But we may be able to have a deprecation schedule towards making Jackson 2 an optional dependency requiring users to explicitly depend on it.

[anatoliy-pylypchuk-kg]

I'm not saying that Temporal should just completely drop Jackson 2 as a dependency. It can still have it as required, but users should be able to exclude it via Maven/Gradle. Temporal SDK should check the available Jackson version dynamically and should still work if Jackson 2 is not available provided that Jackson 3 is available instead. This will not break backward compatibility, but will allow users to be flexible about which Jackson version is on the classpath.

But, as I said, if this is a lot of effort, then it's absolutely ok to not do that right now.

[cretz]

But, as I said, if this is a lot of effort, then it's absolutely ok to not do that right now.

I think this is the case (even if not a lot of effort, definitely would want to be a separate effort from this PR, don't want to combine concerns here). And we may find that if Jackson 2 becomes truly EOL some day, we can be willing to break compat by making Jackson 3 the required dep and asking those w/ custom Jackson 2 code to opt-in to Jackson 2 support.