Puzzles/consume fastly hub experiment

[gustavo-olmedo]

What does this change?

Adds the request-level plumbing required for Frontend to consume the existing Fastly-managed puzzles-new-hub server-side experiment.

This change:

• Adds a shared PuzzlesHubExperiment.isEnabled helper.
• Treats only puzzles-new-hub:variant as enabled.
• Defaults safely to disabled for control, missing, unknown, or malformed participations.
• Reuses the existing ABTests and ABTestingFilter infrastructure.

Testing

Added coverage for:

• Variant and control participations.
• Missing, unknown, and malformed participations.
• Requests that have not been decorated.
• Preservation of unrelated experiment participations.
• Request processing through ABTestingFilter.
• Behaviour when enable-new-server-side-tests-header is disabled.

Run with:

sbt 'common/testOnly test.CommonTestSuite'

Manual verification

Since this PR only introduces the helper and does not include a consumer of it, I verified the behaviour manually by temporarily wiring it to a test banner and toggling its visibility based on the experiment participation. The banner itself was only used for validation and is not part of this branch or the proposed changes.

Screenshots of this manual verification are attached for reference.

Checklist

• Tested locally, and on CODE if necessary
• Will not break dotcom-rendering

[github-actions]

Deploy build 7449 of dotcom:frontend-all to CODE

All deployment options

• Deploy build 7449 of dotcom:frontend-all to CODE
• Deploy parts of build 7449 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[Jakeii]

Hi Gustavo, I've not got any objection to the helper in principle but it could be overkill! What will you be testing that perhaps just ABTests.isUserInTestGroup(TestName, VariantGroup) isn't comprehensive enough?

[gustavo-olmedo]

Hi @Jakeii that's a fair question, the main reason is that I'll be using this with the new web puzzles site, where the experiment is expected to be consumed in navigation, route-driven rendering, and page-level branching. I wanted to have a single semantic entry point for the experiment rather than calling ABTests.isUserInTestGroup(TestName, VariantGroup) everywhere. It avoids repeating string literals, reduces the chance of typos, and makes all the gated behaviour easy to find and remove once the rollout is complete. It also gives us the flexibility to evolve the experiment logic later without spreading test names and variant names across multiple consumers. Admittedly, we haven't fully defined whether we'll need that flexibility yet, so that's a bit more speculative. That said, I still think the first set of benefits makes it worthwhile, especially since, as I mentioned, the whole thing will be removed once the rollout is complete.