Spike editorial ab test register

[abeddow91]

What does this change?

This POC demonstrates how we could introduce a dedicated Editorial A/B Test Register alongside the existing A/B Test Register.

Why?

The existing A/B test register communicates to Ophan what tests the user is participating in and which variants they are being shown.

The Editorial A/B testing framework has two distinct layers:

1. All users are assigned to one of two 50/50 parent variants ("A"/"B") using the existing A/B testing framework. This AB test will be defined in abTests.ts. It will have its own life cycle dictated by status ("ON"/"OFF") and/or expirydate
2. Individual editorial tests are created in the Fronts Tool and passed through to DCR on PressedPage. Each editorial test is identified by a unique string TestUuid and has its own lifecycle, determined by expiryDate and / or hasManuallyEndedOnThisTrail.

These lifecycles are independent. A user may still belong to the parent A/B test while a particular headline test has stopped running. Currently, there is no mechanism for communicating this distinction to Ophan, so we cannot stop reporting participation in an individual editorial test without also affecting the parent test.

Proposed approach

This POC introduces a separate register for editoiral A/B Test.

The benefits of this are

1. prevents the existing register from becoming polluted with "tests" that don't correspond to tests defined in abTests.ts.
2. creates a separation of concerns between the two types of tests. The parent A/B test would only be responsible for bucketing users into variant A or B whilst the individual tests would be responsible for their own lifecycle.
3. Similarly, it also allows for the two lifecycles to be co-exist as it allows individual editorial tests to be removed independently when they expire or are manually ended whilst preserving participation in the parent test so that the user remains eligible for other editorial tests. This means we can stop reporting participation in an editorial test to Ophan when that test is no longer running, without removing the user from the broader Editorial A/B Testing framework.
4. If desired, we can introduce a dedicated model that can represent editorial-specific metadata required by Ophan, such as the test type (headline, image, etc.), variant meta etc. without affecting the current ab test ophan register model. (For this POC, the editorial ab test register uses the same model as the ab test register)
5. The distinction between the two types of tests should also make downstream Ophan analysis clearer.

[github-actions]

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.