Improve codelist update form behaviour when editing slugs

Why are we doing this?

The codelist_update view looks like it allows you to edit a codelist's name or slug or both:

But it doesn't allow you to edit the slug without also editing the name. There is no indication of this prior to trying, it's not clear to the user why this isn't allowed, and the error message if you try to do so is incorrect. This is poor UX.

This slug isn't used by this user (or anywhere) so it's not a "duplicate slug".

The view lives in codelists/views/codelist_update.py, is accessible through the URL pattern codelist/user/{username}/{codelist_slug}/edit/ which is linked on the Edit Metadata button, and invokes action update_codelist. There is code in update_codelist that attempts to handle different types of IntegrityError and determine why the new Handle can't be created, but it doesn't seem to handle at least this case as I expect.

From #1052: The cause is that changing the slug creates a new Handle (which allows us to redirect from the old slug to the new) -- but there's a database constraint that stops two handles belonging to the same owner from having the same name. We catch the IntegrityError, but misinterpret it. It's not clear to me that constraint is necessary.

How will we know when it's done?

The above issues are resolved.

What are we doing?

Options:

• Relax the database constraint, allowing old Handle redirecting to new Handle with different slugs but the same name.
• Clarify that slug change requires name change. Fix error handling / form UI.
• Switch to automatic generation of slugs from the name that can't be edited by the user. This would also affect the API method of creating codelists.

Possibly "slug" is an unhelpful name for a generalist audience. Consider adding help_text to this form.

Defining delivery tasks guidance

Start in codelists/views/codelist_update.py and trace the codelist/user/{username}/{codelist_slug}/edit/ flow to the update_codelist action in codelists/actions.py, especially its IntegrityError handling. Review the competing options and the existing Handle constraint before confirming the intended direction with maintainers. Done means the slug-editing UX and error behavior no longer misrepresent this case.