Generic use of sparse metadata fields

[etj]

Sparse fields have been introduced in #11511 for storing custom fields values for resources.
Handling of such fields is orchestrated by the MetadataManager, following the structure of the json schema, with the addition of multilang fields.

Sparse fields can be anyway used also for "external usage", i.e. for storing data related to dataset but not strictly related to the declared json schema.
For instance, the extraMetadata json field in ResourceBase could be easily and more cleanly stored in a set of sparse fields.

Storing custom data in sparse fields should not conflict with the naming of the metadata fields declared in the json schema, so any access to such fields should be constrained to avoid declared fields.
We may think of an API which grants read access to any sparse field (according to user access permissions to the related resource), but forbids access to sparse fields with declared names.

• GET /resource/<id>/sparse/<sparsekey>
  • check resource read access permission or 404
  • retrieve value
  • 404 on key not found
• PUT /resource/<id>/sparse/<sparsekey> (upsert)
  • check resource read access permission or 404
  • check resource write access permission or 403
  • get the json schema, check if sparsekey is a key of the schema
    • 409 if conflict
  • insert or update sparse field content

Note that this approach, based on jsonschema keys, would also prevent writing sparse key of fields handled by the BaseHander, i.e. fields the are within the ResourceBase table, but this is a wanted behaviour, so there will not be problems when/if some of the base field will be moved to the sparse domain.