Add Spring RabbitMQ plugin

[liuhaolong10]

Fix RabbitMQ trace disconnection and incomplete consumer trace stack (closes #13720)

• Add a unit test to verify that the fix works.
• Explain briefly why the bug exists and how to fix it.

Bug Root Cause

The original instrumentation method in the RabbitMQ plugin is executed in a dedicated thread pool for RabbitMQ message processing, which is not the same thread where consumers execute business logic. This causes trace information loss:

• The plugin can only capture "message consumed" events but cannot track subsequent business operations (e.g., MySQL/Redis calls).
• The traceId cannot be connected between producer and consumer services.

Fix Solution

1. Implement a new instrumentation method for RabbitMQ that aligns with the business logic thread, ensuring traceId continuity between producer and consumer.
2. Modify the original RabbitMQ plugin code to avoid data collection conflicts with the new spring-rabbit plugin.

Additional Notes for New Plugin

The new spring-rabbit plugin solves the problem that the original RabbitMQ plugin cannot collect messages consumed by @RabbitListener annotation, ensuring complete trace collection for spring-rabbit based RabbitMQ consumption scenarios.

• If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #13720.
• Update the CHANGES log.

[liuhaolong10]

@wu-sheng
When I run the test script locally with the command bash ./test/plugin/run.sh -f spring-rabbitmq-3.x-4.x-scenario, it consistently fails to execute successfully. There are two main reasons identified:

1. Timeout when connecting to GitHub.
2. Failure to pull the rabbitmq-server image via Docker.

I have a proxy enabled locally, and accessing GitHub via the browser works without any issues. Despite spending the entire afternoon troubleshooting this test, I still haven't been able to make it run successfully.

Could you please share some tips or best practices that you use when running this test locally? Any guidance would be greatly appreciated.

[wu-sheng]

GitHub is on Azure US, it should not have image pulling issue. Have you rechecked whether this image exists on DockerHub?

[wu-sheng]

From my check of the logs, the server indeed is never booted. Because HEAD:/spring-rabbitmq-3.x-4.x-scenario/case/healthcheck is never responding. Is you app waiting for RabbitMQ server booted properly?

[liuhaolong10]

The health check for spring-rabbitmq-2. x-scenario failed when I ran it around 2 PM.
The health check for spring-rabbitmq-3.x-4. x-scenario passed, but the expected data was incorrect.

In my local runs, most of the health checks don't pass at all.
I am using the rabbitmq:3.8.18 image, which I copied directly from the scenario code in the rabbitmq-scenario test module.
I believe the image itself should not be the problem.

[wu-sheng]

In my local runs, most of the health checks don't pass at all.

Health check should be passed, as it verifies whether the service is ready to send traffic.

[wu-sheng]

1. The 2.x test scenario uses spring-boot-starter-amqp versions 2.0.0.RELEASE through 2.4.0 — these are all EOL Spring Boot 2 versions. Given that 2.x is no longer maintained. We may be better to remove that?
2. Thread name check in RabbitMQConsumerInterceptor is fragile and unreliable
   (rabbitmq-plugin/.../RabbitMQConsumerInterceptor.java)

  if (Thread.currentThread().getName().toLowerCase().contains("springframework")) {
      return;
  }

This is the biggest problem in the PR. Relying on thread names to determine behavior is extremely brittle:

• Thread names are not a contract and can be customized by users or framework versions.
• If a non-Spring application happens to name threads with "springframework", the original RabbitMQ plugin silently breaks.
• If Spring changes thread naming conventions, both plugins break (duplicate spans or no spans).
• This couples the existing rabbitmq-plugin to Spring-specific knowledge, violating separation of concerns.

3. Consider adopting plugin v2 APIs.
4. Supported-list.d should be updated.