Add visibility

The first step for #281.

This MR adds a new 👁️ visibility field at the picture/sequence/upload_set level and a default_visibility at the account and instance level.

Visibility can for the moment have 3 values:

• anyone: the object is visible to anyone
• owner-only: the object is visible to the owner (and later by administrator)
• logged-only: the object is visible to logged users only

This visibility can also be set at:

• picture level
• sequence level
• upload_set level

If not explicitly provided when uploading, the account's default_visibility is used, and if not set, the instance default_visibility.

So changing the default_visibility of a user does not change the existing uploads, only the next ones and likewise, changing the default_visibility of the instance does not change the existing visibility.

It's also now possible to create an upload_set with this visibility, masking its pictures (it might be a nice way to upload pictures, check if everything, clean some stuff, and make them public afterward).

This deprecates the old way of hiding picture/sequence with visible=True|False (but retrocompatibility is kept, visible=False<=>visibility='owner-only'.

In the tiles, we still keep the visible boolean flag for retrocompatibility, and it lives alongside the more precise visibility field.

⚠️ Breaking changes ⚠️

This MR reworks how the permissions are checked to let the database checks them using the new is_picture_visible_by_user / is_sequence_visible_by_user / is_upload_set_visible_by_user functions. This makes it possible to better handle them in the routes like /api/collections. Note that, to display a picture, we always needs to check the picture's visibility and it's collection (the upload_set's visibility is copied to all its associated collections).

But before, we supported a way for the metacalog to know the deleted collections using a status filter like status IN ('deleted','ready'). We also used to consider hidden sequences as deleted for the metacatalog to forget them.

This was leading it to leak too much information on hidden collections as we were returning STAC response (so leaking and dates, never pictures).

This MR remove the status filter and replaces it by a new show_deleted boolean parameter to /api/collections, that accepts to not return fully STAC compliant response for deleted / hidden collections (we only return their ID and deleted status).

An ugly retrocompatibility has been kept to consider that status IN ('deleted','ready') is equivalent to show_deleted=True, but all other uses of the status filter are now forbidden.

Side changes

We now got a 404 instead of a 403 when accessing hidden picture.

Split the old status into several fields

The old status was used to store the processing status of a sequence/picture and the fact that it was hidden or not. Now those are stored in visibility/processing_status for the pictures.

So are now able to hide a picture while it's being processed, and we'll be able to remove the status field later on. (we still need it not to break the deployment of this code).

Questions

Naming

Is visibility and anyone/ owner-only / logged-only the best way to name those concepts ?

Maybe access_permissions with public / owner-only / logged-only ?

🤷‍♂️

🚧 Work still in progress

• Benchmark since a lot of SQL queries have been rewritten.

Benchmark

The first implementation was flexible (we were checking the first non null visibility in the order picture > sequence > upload_set > account > instance but this was impacting too much the underlying SQL queries.

Work to be done after

This MR will also need to be integrated on the website (to be able to set/update the visibility of an upload_set / account at least, and update the hidding mechanism at the picture/sequence level). Issues need to be created.

We might also need later a way to hide all collections of a given user, but this could be done in a separate MR (and not right away, we need to be sure it's needed).