change: make extension versions immutable

[netomi]

This PR modifies the default behavior of the registry such that extension versions are immutable.

Deleting an extension version does not remove it from the database, but instead marks is as deleted so that the same version can not be published again. Extension files uploaded to the cloud storage are deleted, so it is not possible to undelete a version again.

Additionally, there is now a purge mechanism for admins to be able to remove extension versions completely from the database as well.

The UI has also been refactored to better display the status of extension versions.

This fixes #1805

[cstamas]

Supersedes #1866

[netomi]

This is how the extension admin page for an extension with deleted versions looks like:

[netomi]

The UI changes include various fixes that were existing, for example from the namespace admin page you were redirected to the user settings of the extension where you could not delete them as an admin. Another things was that it was not visible whether a version is active or not, so this is now also included so that as an admin you immediately see that without needing to query the DB.

The refactoring also make sure components that are used from the admin dashboard and user settings are now shared in src/components to make it cleaner.

[netomi]

I decided against an additional enum for the state to keep things as simple as possible as to focus on correctness and making sure we do not add any regression and fix the UI accordingly which was pretty much broken in this regard.

In a follow up step we should cleanup the different states an extension can be in, but this will take some time and we need to have the soft-delete as a basis for other work.

[cstamas]

re Backend changes: LGTM, one observation: extension_version table is now having 39 columns!

re Frontend changes: Ponytail remark:

webui/src/components/extension/extension-card-list-item.tsx:L153: delete: canDelete prop threaded through ExtensionCardList → NamespaceExtensionList → ExtensionCardListItem but never read in the leaf component's JSX. Drop the prop and its pass-through in extension-card-list.tsx:L20/L42, namespace-extension-list.tsx:L91/L105, user-settings-extensions.tsx:L89.

[cstamas]

I decided against an additional enum for the state to keep things as simple as possible as to focus on correctness and making sure we do not add any regression and fix the UI accordingly which was pretty much broken in this regard.

In a follow up step we should cleanup the different states an extension can be in, but this will take some time and we need to have the soft-delete as a basis for other work.

Yes, I wanted exactly to ask this, as perso, I liked more the "enum way" @gnugomez started with. Right now, we have two related boolean columns (there is clearly a logical dependency between the two; maybe even more) but are implemented as independent from each other.

[netomi]

The reason against an enum with state is that you need to have a state machine that ensures what transitions are possible or allowed. We certainly want a state for an extension to also cover cases like:

• scan results
• publisher agreement missing
• ... other cases you can imagine

but this is not something I would do light-heartily so I would like to postpone that to get the immutable version stuff in.

[netomi]

I know that 39 columns is bad, also considering that we use jooq and we need to explicitly select the columns we want to retrieve which is easy to miss. This is certainly an area that needs improvements and the reason why I am afraid to touch that code.

[autumnfound]

Java code generally LGTM, can't speak on the React code and I don't have capacity to test immediately. I don't love that we're as light as we are on tests since this is such an impactful change.