Fix instrumentation for WebFlux with Spring 6.x

[eyalkoren]

What does this PR do?

Fixes #2935
I locally managed to successfully run the entire WebFlux instrumentation plugin tests with spring-web 6.0.3 and spring-boot 3.0.1 with only this small change in the instrumentation, so I think it may be enough.

Adding the tests require some more efforts and we should probably add a dedicated spring-boot 3.x test and possibly upgrade the spring-boot we test with in other modules, so if this fix is verified, tests will be included in a separate PR.

Checklist

• This is a bugfix
  • I have updated CHANGELOG.asciidoc
  • I have added tests that would fail without this fix - only added unit tests to verify proper loading of the right implementation per Spring version. Full WebFlux and other Spring tests will be covered through Add support for Spring 6.x and Spring Boot 3.x #2942

[eyalkoren]

And a few more minutes thinking about it - it is insufficient to change the source, the bytecode would still contain the wrong method signature 🤦‍♂️
I'll add a separate module that compiles with spring-web 6 and only abstract out the int getStatusCode() functionality

[ghost]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-01-23T16:05:09.139+0000

• Duration: 90 min 48 sec

Test stats 🧪

Test	Results
Failed	0
Passed	8787
Skipped	113
Total	8900

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run benchmark tests : Run the benchmark tests.

• run jdk compatibility tests : Run the JDK Compatibility tests.

• run integration tests : Run the Agent Integration tests.

• run end-to-end tests : Run the APM-ITs.

• run windows tests : Build & tests on windows.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[eyalkoren]

I used this fix to set up the stage to switch to the following state:

• build and test on JDK 17 by default
• enforce Java 11 syntax compatibility by default
• build and test weekly on JDK 11
• build and test weekly on JDK 19 (requires upgrade of jacoco and closes Building & testing project with JDK 18 #2328)
• have an infrastructure that allows modules that must be compiled with Java 17

The latter was achieved through maven profile, as follows:

• Java-17-dependent code will reside under a top-level module called apm-agent-java-17
• The apm-agent-java-17 module is not meant to contain code, only to serve as a parent to other modules
• One example for a module that requires compilation with Java 17 is apm-agent-spring-6, a child of apm-agent-java-17
• We use the non-java-11 profile to exclude the apm-agent-java-17 module entirely from build when not running on Java 11. NOTE: this is a restriction as it assumes that the only pre-Java-17 we build with is 11
• We use the non-java-11 profile also to include the modules with actual code, such as apm-agent-spring-6, when packaging

[github-actions]

/test

[eyalkoren]

For now I treated this as a bug fix, postponing the documentation of it as supported to #2942