deprecate pipeline bus v1

[yaauie]

Release notes

• Deprecates v1 of the pipeline bus; the v2 implementation has been the default since its introduction in Logstash 8.15.0

What does this PR do?

Adds a deprecation warning if Logstash is configured to use the legacy v1 pipeline bus. The legacy implementation was replaced with a more-performant one in 8.15.0, and v1 was only left in place as an "escape hatch".

The ability to select v1 implementation is set to be removed on main in advance of 9.0 via #16644

Why is it important/What is the impact to the user?

It should have no user impact; the escape hatch was never documented, and is not expected to be used in the real world.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] I have made corresponding change to the default configuration files (and/or docker env variables)
• I have added tests that prove my fix is effective or that my feature works

How to test this PR locally

1. add -Dlogstash.pipelinebus.implementation=v1 to config/jvm.options
2. start logstash
3. observe relevant entry in the deprecation log

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: e18e466

[donoghuc]

The addition of the logger commit makes sense. Im a bit confused about the retrofit test commit though c51a7d5 is that refactor a general update that is extending a pattern being applied elsewhere you could point me to?

After looking closer:

I see organizational improvements and some more formal coverage of the PipelineBus factory when different configurations are provided using the withSystemProperty helper. Seems reasonable and generally just an improvement to the existing coverage.

[donoghuc]

I think this was just moved around, not introduced but I think its unused.

[yaauie]

Yeah, the first commit just retrofits tests onto the bit that selects which implementation to use, and needed to wrap the existing @Parameterized tests in a @RunWith(Enclosed.class) so that the new tests would run just once instead of for each possible value of the parameter. I made the change in a separate commit because it doesn't actually change anything.

As you saw, the star of the PR is the second commit, which adds the deprecation log and verifies that it is emitted in the right conditions. In retrospect, the other two tests should have a negative assertion.

I'll add those and bounce it back.