Allow control over which dataset types are available, per collection

[pdurbin]

Proposed rules:

• If only the default dataset type of "dataset" is present, it can be used by anyone in all collections (as long as you have permission).
• At the system level, a superuser can add additional dataset types.
• If multiple dataset types are available:
  • by default, collections can use the default dataset type of "dataset" and all other types are not allowed.
  • at the collection level, superusers can enable non-default types and even disable the default type.
• No inheritance, just like our permission system. All control is at the collection level.

We'll implement this as API-only. Normal CRUD operations will be available.

Just an idea of how the API might look, from Option A2 of our design doc:

curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/dataverses/collection1/allowedDatasetTypes" -d '[review]'

[poikilotherm]

I haven't had a chance to pick up the work on dataset versions PIDs, but I did like what we discussed back then how this feature should be handed down.

Adapting what we discussed back in #9462 to this, I suggest we don't do it the way we do permissions.
For us, a very hierachically organized installation, it would be a lot of extra work to configure every collection on their own.
Also, an installation may want to not use a hardcoded single type "dataset", but a different one instead.
So let's follow "convention over configuration", making both ways possible (I do get that for Harvard your proposed way may be a better fit).

(When taking up the work on the dataset version PIDs again, I'd use the same logic to keep things consistent.)

Instance wide settings

• A superuser can limit what types are actually available instance wide (they need to install them if more than "dataset" is wanted)
• A superuser can configure a fallback type by ID. If not set, the type with the lowest ID will be used.
• A superuser can configure if types should be inherited from the parent collection or not.

Collection settings

1. Inheritance active:
   • (Anyone with admin privileges|a superuser)* on the root collection may make a choice what types shall be available in it.
   • No choice on the root means only the type configured as fallback type is allowed for backward compatibility.
   • Any collection 'down the tree' will by default inherit from its parent what types should be allowed. (So the root will provide a default for them)
   • At any point, (anyone with admin privileges|a superuser)* on a collection may break the inheritance chain by overriding and explicitly setting allowed types.
   • If the parent of a collection has no explicit configuration, the tree is traversed up to the root until an explicit configuration is found. (Maybe even falling back to the dataset-only default.)
2. Inheritance inactive:
   • (Anyone with admin privileges|a superuser)* on a collection can explicitly set allowed types.
   • The option "inherit" cannot be used and the tree is not traversed

Avoiding edge cases

• Make sure via Flyway that if no type is installed, the "dataset" type gets auto-applied (so an installation may still choose to only allow a different type)
• The auto-applied type will probably have the lowest ID, so making "dataset" the configurable fallback type.
• Do not allow to delete any type that is in use and not to delete the only remaining type.

*) Not sure what's a better fit. For our installation, we probably would prefer our data stewards to be able to make these choices. Maybe it should be a new permission bit, so installations may be able to choose which way to go? (And by convention only allow superusers.)

[pdurbin]

@poikilotherm I hear you but here's my initial implementation, at least: ef981f3

Happy to discuss!