Rework WP.com e2e tests to remove custom test harness and run in CI

[jkmassel]

Summary

• Refactor WordPress.com e2e tests to use libtest-mimic for a cargo-test-like CLI experience
• Add WordPress.com e2e tests to the Buildkite CI pipeline

Test plan

• Run cargo build -p wp_com_e2e to verify the refactored test runner compiles
• Run ./target/debug/wp_com_e2e --list to verify test discovery works
• Run ./target/debug/wp_com_e2e with WP_COM_API_KEY set to verify read-only tests pass
• Verify the new Buildkite pipeline step executes successfully

---

Changes

The main refactor replaces the ad-hoc test execution in wp_com_e2e with libtest-mimic, providing:

• Standard test CLI flags (--list, --ignored, --include-ignored, --exact, --nocapture)
• Test filtering by name/pattern
• Separation of read-only vs write tests (write tests are ignored by default)
• Shared TestContext for API client reuse across tests
• Dynamic test generation based on API responses (per-site, per-conversation tests)

The CI addition runs the read-only e2e tests on the android queue after installing Rust toolchains.

We'll run the new tests as not-required for now to see how it goes and will make them required for a PR to land in the future.

[crazytonyli]

I'm not sure if I asked this before (I forgot the answer if I did). Any reason we don't run this test suite like other tests, using cargo test?

The "ignore write tests" part of this PR seems to be similar to cargo features.

[crazytonyli]

Should we use cargo to run the tests? Like cargo run --quiet --bin wp_com_e2e -- [cli-options]?

[jkmassel]

Good point! Adjusted in 37d479e

[jkmassel]

Any reason we don't run this test suite like other tests, using cargo test?

This is pretty much what this PR does, but it maintains the ability to build the binary and run it externally.

[crazytonyli]

Sorry, I don't quite follow. We can use commands like cargo test -p wp_api_integration_tests to run other tests, but we can't cargo test -p wp_com_e2e.

it maintains the ability to build the binary and run it externally.

Why do we need to build an executable binary for this end-to-end test suite? By "externally", do you mean it's used in somewhere else?

[jkmassel]

Why do we need to build an executable binary for this end-to-end test suite? By "externally", do you mean it's used in somewhere else?

The idea behind the crate is that it can be compiled into a binary that could be run from Docker or as part of WP.com's CI process to validate that a given PR doesn't break API client compatibility.