fix(bdd): make ./scripts/run-bdd-tests.sh actually support FEATURE flag

[chengxilo]

Which issue does this PR address?

Relates to #2148

Rationale

In master branch, the ./scripts/run/bdd-tests.sh doesn't support choosing a feature, while there is a FEATURE varaible.
While this script is mainly for BDD test in CI, when we implement the bdd test it is also very helpful to verify if the BDD test works. So I hope this can be improved so when I build new test scenario, it won't take me 10 minutes to build and run everything everytime I wanna test it.

What changed?

In master branch, the ./scripts/run/bdd-tests.sh doesn't support choosing a feature, while there is a FEATURE varaible. I splitted the docker-compose file for each .feature. Now when run basic_messaging scenario we only need to build and run the docker-compose.server.yml which create a single server, while in leader_redirection scenario we use docker-compose.server.yml and docker-compose.cluster.yml together. It should increase the speed to run the run-bdd-tests.sh

the clean is also updated by claude, but I think it makes sense so I kept it. Now if we use ./scripts/run/bdd-tests.sh clean, it should clean up everything that is possible to be booted but failed to be removed. I didn't actually use it tho.

And one extra change which is technically not in the scope, I removed go-race test in bdd, as I realized that it was a mistake to provide -race test in BDD test. It is only applicable for unit test with mock server.

Local Execution

• Passed
• Pre-commit hooks ran

AI Usage

1. Claude Opus 4.6
2. Code generation, I'm not good at writing shell script so it helps a lot.
3. The code was manually modified after generation
4. yes

[github-actions]

Thanks for the PR. It is labeled S-waiting-on-review and queued for review.

Slash commands (own line, regular comment) move it around the queue:

• /ready - back to S-waiting-on-review after addressing feedback
• /request-review @user-or-team - request a reviewer

See CONTRIBUTING.md for details.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.61%. Comparing base (a8dd3a9) to head (619a340).

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3384      +/-   ##
============================================
- Coverage     74.65%   74.61%   -0.04%     
  Complexity      943      943              
============================================
  Files          1228     1228              
  Lines        120529   120529              
  Branches      97263    97292      +29     
============================================
- Hits          89975    89928      -47     
- Misses        27614    27623       +9     
- Partials       2940     2978      +38     

Components	Coverage Δ
Rust Core	75.83% <ø> (-0.02%)	⬇️
Java SDK	58.44% <ø> (ø)
C# SDK	69.41% <ø> (-0.45%)	⬇️
Python SDK	81.06% <ø> (ø)
Node SDK	91.44% <ø> (-0.10%)	⬇️
Go SDK	40.20% <ø> (ø)
see 27 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[hubcio]

one thing to confirm rather than a code issue: this PR drops the go -race BDD task (bdd-go-race, the -race flag and GO_TEST_EXTRA_FLAGS plumbing). no dangling references remain and the CI matrix entry goes away cleanly, so the removal itself is clean. worth a conscious sign-off on losing the data-race signal though - -race instruments the go test binary's own goroutines regardless of whether the server is real or mocked, so the "only applies to unit tests with a mock server" rationale isn't quite right. note coverage-baseline.yml still runs go test -race against tests/tcp_test, so some race coverage survives there.

[chengxilo]

one thing to confirm rather than a code issue: this PR drops the go -race BDD task (bdd-go-race, the -race flag and GO_TEST_EXTRA_FLAGS plumbing). no dangling references remain and the CI matrix entry goes away cleanly, so the removal itself is clean. worth a conscious sign-off on losing the data-race signal though - -race instruments the go test binary's own goroutines regardless of whether the server is real or mocked, so the "only applies to unit tests with a mock server" rationale isn't quite right. note coverage-baseline.yml still runs go test -race against tests/tcp_test, so some race coverage survives there.

Sorry it was a huge mistake. Fixed.

I removed the -race from the coverage tho, since it only only cause nagative impact and we don't need race detection for coverage report.

[chengxilo]

/ready

[chengxilo]

It's kinda funny that the CI system keeps collapse because of the device space.