Lower minimum Java version from 17 to 11

[andreaTP]

Ref: #836

Opening in draft, to show what would be needed.

Downgrade the compiler target and all dependencies that required Java 17+ so the SDK can be consumed by projects still on Java 11.

Key changes:

• Jackson 3.x (tools.jackson) -> Jackson 2.x (com.fasterxml.jackson)
• Caffeine 3.2 -> 3.1, Micrometer 1.17 -> 1.13
• JUnit 6 -> 5, Testcontainers 2 -> 1
• Convert 22 records to regular classes
• Remove sealed/permits from 5 class hierarchies
• Replace String.formatted(), Stream.toList(), HexFormat, switch expressions, pattern-matching instanceof, and text blocks with Java 11-compatible equivalents
• Add jackson-datatype-jsr310 for ZonedDateTime support
• CI matrix now includes Java 11

Description

Testing done

Submitter checklist

• I have read and understood the CONTRIBUTING guide
• I have run mvn license:update-file-header, mvn spotless:apply, pre-commit run -a, mvn clean install before opening the PR

[andreaTP]

I took a first pass at the changes needed to support Java 11, so we can continue the conversation with something concrete.

Most of the changes are fairly mechanical, although having to downgrade some dependencies is, of course, not ideal.

I’ve tried a few different approaches, and this seems to be the most promising one so far. Since this work is also helping me land at least a couple of PRs in Endive, I’d like to propose that I maintain the Java 11 branch, at least for some time, and publish releases from the [roastedroot](https://github.com/roastedroot) organization.

I’ll make sure to preserve all the appropriate attributions and document the history and rationale clearly. This way, in a few months, we can also start tracking actual usage and make a better-informed decision about whether(and to what extent) it makes sense to streamline or discontinue support for older Java versions.

I hope this approach sounds reasonable, and I’m very happy to discuss or adjust it based on your feedback.

[jonesbusy]

Yea downgrading the libraries is definitely a no go. Specially Jackson3. This is quite a lof of changes

Jenkins a known top consumer is already having such dependency as API plugin: https://github.com/jenkinsci/oras-java-api-plugin/blob/main/pom.xml#L68-L71

Maintaing a Java 11 baseline with other dependencies is definitly a no go and too much work. And definitely a breking changes for other clients

I think maintaining a fork from oras-java into your organisation (and publishing to your own maven central namespace is probably the best for now. Until you decide to raise the minimum baseline to Java 17