feat: exclusive 'Or' option in checklists

[jamdelion]

🎟️ Trello ticket: https://trello.com/c/dXUW9EC1/3146-add-or-option-to-checklists

In this PR:

• Added a feature flag for this: EXCLUSIVE_OR
• Added another listManager to Checklist editor modal to add an 'exclusive or' option when there is at least one other option. It has a maxLength of 1.
• exclusiveOr option is styled with an 'or' before it in public component
• Other checkboxes become deselected if the exclusiveOr option is selected

⚠️ Note: grouped options currently not accounted for in this PR - the exclusiveOr select does not appear when 'expandable' is toggled.

Still to do...

• A11y review
• Deal with the grouped options case

Screenshots

Before	After
Options editor before an exclusive option has been added
Options editor with exclusive option added - button is greyed out
Public facing checklist

[github-actions]

Removed vultr server and associated DNS entries

[jamdelion]

Extracted these test helpers out with their pointerEventsCheck explanation to make the test files a little bit cleaner 🧼

[DafyddLlyr]

Looking great!

I'm getting a ShareDB issue on the Pizza each time I make a change to the flow but can't recreate this locally. Each time I send a websocket request to ShareDB (e.g. updating a node) it times out and I end up with an endless spinner. This happens from time to time on pizzas or locally - destroying and rebuilding the Pizza should solve this.

Some minor comments on the code, no show stoppers.

A few things to consider -

The interaction with the allRequired prop
It's possible to trigger this error state but not resolve it by checking the exclusive "or" option. We could resolve this via the UI but truth is that having allRequired and an exclusive option or actually contradictory and we should expose this to Editors. I'd be in favour of adding this as a rule to the validation schema for this component.

Single exclusive option
This is currently enforced by the UI using the maxItems prop. Again, I think this is worth being explicit about and having a check in our validation schema for this component to enforce. This is a bit more defensive and allows for UI drift in future without losing the intention of how this should work and behave.

[DafyddLlyr]

There's possibly a number of places where this could be reused -

• Checkboxes in the List component
• Checkboxes in the Planning Constraints component
• I'm sure there's one or two more!

This is needed because we're not using Formik to totally control the state of these checkboxes using the Field component so have to do it manually https://formik.org/docs/examples/checkboxes

This would be a nice follow up PR to try and address 👌

[jamdelion]

Completely agree, I will follow-up on this in the next PR, and also split up some of the component files a bit more.

[DafyddLlyr]

It could be quite nice to split some of these sections up into their components so that the structure if overall more discernable at a glance. Right now it's quite nested and complex to follow.

The catch here is that we need formik in all of them.

We can certainly prop drill this along, or wrap the children in FormikContext and then access the values via the useFormikContext() hook. There's a good example of this in the invite to pay and GovPay metadata sections of the code base 👍

This can for sure be another PR or a fix-forward issue and doesn't need to be directly addressed here.

[DafyddLlyr]

Appreciate the follow up changes here - all looking good!