refactor kafka cross tracer tests to use only java buddy

[wconti27]

Motivation

We want one feature for kafka testing, not one per language like initially implemented

Changes

Eliminates all but one test class for Kafka cross tracer testing. Uses the java buddy since Java context propagation is fully implemented for kafka

Workflow

1. ⚠️ Create your PR as draft ⚠️
2. Work on you PR until the CI passes (if something not related to your task is failing, you can ignore it)
3. Mark it as ready for review
   • Test logic is modified? -> Get a review from RFC owner. We're working on refining the codeowners file quickly.
   • Framework is modified, or non obvious usage of it -> get a review from R&P team

🚀 Once your PR is reviewed, you can merge it!

🛟 #apm-shared-testing 🛟

Reviewer checklist

• Relevant label (run-parametric-scenario, run-profiling-scenario...) are presents
• No system-tests internal is modified. Otherwise, I have the approval from R&P team
• CI is green, or failing jobs are not related to this change (and you are 100% sure about this statement)
• A docker base image is modified?
  • the relevant build-XXX-image label is present
  • To R&P team: locally build and push the image to hub.docker.com
• A scenario is added (or removed)?
  • Get a review from R&P team
  • Once merged, add (or remove) it in system-test-dasboard nightly

[robertomonteromiguel]

I guess the failures on the CI are related with these changes. I change the status of the PR as "Draft"

[cbeauchesne]

We want one feature for kafka testing, not one per language like initially implemented

Could you add more context for that decision, just to allow futur contributor to understand the why?

cc @wantsui

[cbeauchesne]

no need to rebuild buddies image here

[wconti27]

We want one feature for kafka testing, not one per language like initially implemented

Could you add more context for that decision, just to allow futur contributor to understand the why?

cc @wantsui

@tabgok and I discussed this. The reasoning to only have one buddy as opposed to one per language is mainly to speed up testing. If trace context propagation works for language A to language B, and also works from language A to language C, then it can be inferred that propagation works from language B to language C. It also works better with the layout of the Feature Parity Dashboard.

[cbeauchesne]

The reasoning to only have one buddy as opposed to one per language is mainly to speed up testing.

Indeed it'll be faster :)

It also works better with the layout of the Feature Parity Dashboard.

We need to make the FPD handling any use case. If one day it's the only reason the shape a tests, please ping us to find a solution, because tests design must not be driven by this reason. (And actually, I think it could have handled this use case nicely, because we could have grouped all tests in one feature).

---

So far, AGTM!