Bumped to SpringBoot4, SpringFramework7 and JDK17 - same as #705, but with signed-ff commits

[jacekbilski]

The content is the same as in #705, see the discussion there. The only two changes are: the commits are now properly signed-off and I've rebased it onto main.

[lehphyro]

Hey guys, are you planning to merge this soon? It's blocking Spring Boot upgrades because of Jackson 3 breaking changes.

[jacekbilski]

I wish I could say more. I believe that @stromner-stralfors and I have made all the necessary changes, the code works for me™. Anything beyond that is in the hands of the maintainers.

[lbenedetto]

@duglin Can you answer if this is something you (the maintainers, not specifically you) will be working on?

[duglin]

@lbenedetto let me poke some folks

[duglin]

Seems reasonable to me, however, with such a large number of files changed (and some being more than just a version number change), let's wait for @Cali0707 to verify that nothing seems off.

[Cali0707]

yes currently taking a look here (started yesterday, but lots of changes...)

[Cali0707]

Hey @jacekbilski thanks for all the much needed hard work to modernize this SDK!

I think to make these changes more releasable we need to split this up into a couple more incremental PRs/releases:

1. Let's mark http/restful-ws's public classes as @Deprecated(forRemoval = true). As part of this, we should copy the code into http/restful-ws-jakarta and permanently switch the javax to jakarta namespacing. We do not want to remove the restful-ws-jakarta support in 5.0 (and can't remove either currently as neither module is actually marked as deprecated, despite the commit comment saying they are).
2. Make a 4.1.0 release after step 1 is merged
3. Bump to Java 17 baseline and apply the language modernization changes (version bump to 5.0.0-SNAPSHOT)
4. Drop the restful-ws module and update restful-ws-jakarta to Jakarta REST 4.0
5. Apply the HttpHeaders defensive copy fix and the @Nullable annotation switch (these are both needed for Spring Boot 4 forward compatibility), but keep compiling and testing against Spring Boot 3.x. This way users on both 3.x and 4.x can use the module. I thinking moving from the current 2.x all the way to 4.x in one go is too aggressive and will make it so some users can not use this.

I don't think we need to bump to Jackson 3 currently, as there is still a large portion of projects on Jackson 2. Additionally, let's stick with JUnit 5 for now to help keep the scope of changes smaller.

If you are able to start working on pieces of this in separate PRs, ping me and I'm happy to try to quickly merge them and move this process along!