[#2899] Integrate OpenKlantConfig and OpenKlant2Config

[pi-sigma]

No description provided.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 89.89899% with 20 lines in your changes missing coverage. Please review.

Project coverage is 94.12%. Comparing base (235d0f0) to head (9becba5).
Report is 10 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/open_inwoner/openklant/models.py	65.62%	11 Missing ⚠️
src/open_inwoner/cms/cases/tests/test_htmx.py	11.11%	8 Missing ⚠️
src/open_inwoner/openklant/admin.py	95.23%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1520      +/-   ##
===========================================
- Coverage    94.13%   94.12%   -0.02%     
===========================================
  Files         1064     1067       +3     
  Lines        39286    39337      +51     
===========================================
+ Hits         36982    37025      +43     
- Misses        2304     2312       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pi-sigma]

@swrichards Keeping the service field on the OpenKlant2Config non-nullable is problematic when attempting to update the config for the first time: the get_or_create in the admin's change_view raises an IntegrityError because no zgw service is provided. I worked around this by creating a default API service and displaying a message to the user that they should update the service. However, it might just be simpler to make the field nullable, as in the old OpenKlantConfig. Unless you can think of some other way around this?

[swrichards]

@swrichards Keeping the service field on the OpenKlant2Config non-nullable is problematic when attempting to update the config for the first time: the get_or_create in the admin's change_view raises an IntegrityError because no zgw service is provided. I worked around this by creating a default API service and displaying a message to the user that they should update the service. However, it might just be simpler to make the field nullable, as in the old OpenKlantConfig. Unless you can think of some other way around this?

@pi-sigma I am happy making the field nullable.

The general problem we have is that we want to know if the eSuite/OK2 service is correctly configured, and that does not play nice with SingletonModel as you say, because you have to be able to create it with sane defaults without user input. For now, I think we have to tackle this in our Service constructors: that is where we should fail loudly if:

1. OpenKlant2 is configured as the primary
2. But there is no service defined

Arguably we could also do this in the validation step for the global ok admin: if ok2 is selected there, you get a warning to first configure a service.

[swrichards]

Good job, looks a lot better IMO.