So that we can properly use Formik for the configuration form.

So that we can properly use Formik for the configuration form.

There are some slight tweaks in literals here and there, and the
selects are now react-selects that can be searched, but other than that
they're pretty much equivalent to what we had before.

react-select sets the value to null, which doesn't have a property
'value', leading to crashes. Instead, we set the formik field value
to 'undefined', which effectively clears it in the formik state.

* The modal spacing is a cheeky workaround for tab error icons that would
  otherwise be cut off by the overflow: auto due to the desired scroll
  behaviour inside a form modal.
* The react-select styles ensure the border color of the select is consistent
  with other input types in the django admin style (red border if there are
  validation errors)
* The changelist styles ensure that items in a table row with validation
  errors don't break the (vertical) alignment between them - as soon as
  any has a validation error, its content will be pushed down so we need
  to align to the bottom of the table cell (like in the variables table
  styles).

The layout is still the same, except this table will no longer live in its own
modal, but be a tab in the main modal for the registration options instead.

The fields now make use of Formik's FieldArray to manage a list of nested
objects.

Moving the ZGW options into a modal allows us to make use of Formik,
since the fields themselves are now properly isolated and we can
add an explicit 'submit' button to commit the configuration back
to the main state. This applies a similar set up like in the objects
API registration options.

The configuration is now broken into parts too - base ZGW options
go in the first tab, while the case property configuration is
moved to its own tab rather than sticking it in a modal itself (
modal in modal is not a user friendly UI).

I'm not sure if putting the objects API options in a fieldset or
maybe its own tab is the best approach, we can discuss.

* Added case with validation errors
* Added some more options to confidentiality level select

* setValues takes a callback for previous values, so that we can avoid
  form data races/stale values
* removed unused import
* fixed the handling for setting the default API group, the ternary
  was not being evaluated as expected (uncovered via ZGW options and
  this applies the fix here too)

There are some slight tweaks in literals here and there, and the
selects are now react-selects that can be searched, but other than that
they're pretty much equivalent to what we had before.

react-select sets the value to null, which doesn't have a property
'value', leading to crashes. Instead, we set the formik field value
to 'undefined', which effectively clears it in the formik state.

* The modal spacing is a cheeky workaround for tab error icons that would
  otherwise be cut off by the overflow: auto due to the desired scroll
  behaviour inside a form modal.
* The react-select styles ensure the border color of the select is consistent
  with other input types in the django admin style (red border if there are
  validation errors)
* The changelist styles ensure that items in a table row with validation
  errors don't break the (vertical) alignment between them - as soon as
  any has a validation error, its content will be pushed down so we need
  to align to the bottom of the table cell (like in the variables table
  styles).

The layout is still the same, except this table will no longer live in its own
modal, but be a tab in the main modal for the registration options instead.

The fields now make use of Formik's FieldArray to manage a list of nested
objects.

Moving the ZGW options into a modal allows us to make use of Formik,
since the fields themselves are now properly isolated and we can
add an explicit 'submit' button to commit the configuration back
to the main state. This applies a similar set up like in the objects
API registration options.

The configuration is now broken into parts too - base ZGW options
go in the first tab, while the case property configuration is
moved to its own tab rather than sticking it in a modal itself (
modal in modal is not a user friendly UI).

I'm not sure if putting the objects API options in a fieldset or
maybe its own tab is the best approach, we can discuss.

* Added case with validation errors
* Added some more options to confidentiality level select

* setValues takes a callback for previous values, so that we can avoid
  form data races/stale values
* removed unused import
* fixed the handling for setting the default API group, the ternary
  was not being evaluated as expected (uncovered via ZGW options and
  this applies the fix here too)

Updated to 0.33.0 for the document-types endpoints refactors from the
UX rework ticket (#4606).

Refactored the components and hooks so we can lift up the retrieval of
available catalogues in a ZGW API group.

The parent component is now responsible for fetching the available
catalogues and relays the loading/error state from useAsync. It also
encapsulated the derived catalogueUrl when a valid value is available
and selected, which other components need to look up related objects
(like case types, document types, products and the future role types).

I've opted to pass down the error into a component that just throws
for the existing error boundary behaviour and location, as it's
important that you can still change the API group to trigger a new
attempt and we want to keep the code nicely organised.

Finally, some more fieldsets were abstracted into their own components
for readability reasons.

Refactored the components and hooks so we can lift up the retrieval of
available catalogues in a ZGW API group.

The parent component is now responsible for fetching the available
catalogues and relays the loading/error state from useAsync. It also
encapsulated the derived catalogueUrl when a valid value is available
and selected, which other components need to look up related objects
(like case types, document types, products and the future role types).

I've opted to pass down the error into a component that just throws
for the existing error boundary behaviour and location, as it's
important that you can still change the API group to trigger a new
attempt and we want to keep the code nicely organised.

Finally, some more fieldsets were abstracted into their own components
for readability reasons.

…rybook

Only affected the stories, as the Formik initialValues is initialized
incorrectly there.

Instead of having to enter the values in a text box, you can now
select them in a dropdown.

Refactored the components and hooks so we can lift up the retrieval of
available catalogues in a ZGW API group.

The parent component is now responsible for fetching the available
catalogues and relays the loading/error state from useAsync. It also
encapsulated the derived catalogueUrl when a valid value is available
and selected, which other components need to look up related objects
(like case types, document types, products and the future role types).

I've opted to pass down the error into a component that just throws
for the existing error boundary behaviour and location, as it's
important that you can still change the API group to trigger a new
attempt and we want to keep the code nicely organised.

Finally, some more fieldsets were abstracted into their own components
for readability reasons.

…rybook

Only affected the stories, as the Formik initialValues is initialized
incorrectly there.

Instead of having to enter the values in a text box, you can now
select them in a dropdown.

Given a particular catalogue and case type identification, retrieve the
role types defined within.

We exclude the initiator role type from this list, since creating any
additional roles with type initiator would lead to broken integrity,
as the authentication details/registration attributes are used by the
plugin already to set the initiator, and only one initiator can (and
must) be set on case.

Given a particular catalogue and case type identification, retrieve the
role types defined within.

We exclude the initiator role type from this list, since creating any
additional roles with type initiator would lead to broken integrity,
as the authentication details/registration attributes are used by the
plugin already to set the initiator, and only one initiator can (and
must) be set on case.

* Created a case type with same identification in different catalogue
* Added same role type in different case types (see above + in draft
  case type)

The underlying API data is compatible already, so we can keep rendering
the textfield to avoid breaking configurations if no case type
identification is specified yet. Once one is selected, the UI
automatically upgrades into a dropdown.

The zaakIdentificatie filter parameter does not exist in these
old versions.

…rybook

Only affected the stories, as the Formik initialValues is initialized
incorrectly there.

Instead of having to enter the values in a text box, you can now
select them in a dropdown.

Given a particular catalogue and case type identification, retrieve the
role types defined within.

We exclude the initiator role type from this list, since creating any
additional roles with type initiator would lead to broken integrity,
as the authentication details/registration attributes are used by the
plugin already to set the initiator, and only one initiator can (and
must) be set on case.

* Created a case type with same identification in different catalogue
* Added same role type in different case types (see above + in draft
  case type)

The underlying API data is compatible already, so we can keep rendering
the textfield to avoid breaking configurations if no case type
identification is specified yet. Once one is selected, the UI
automatically upgrades into a dropdown.

The zaakIdentificatie filter parameter does not exist in these
old versions.