Schedule back origins with visit_type "deb" (ongoing)

Same done in production.

Triggered some debian loading in there.
And everything is working as expected.

staging deployment done ^

Copy of an email I sent on 2021-11-17:

At least loader deposit and npm [1] are fine.

Here is an overview of the fields (+ internal version name + branch name) used by each package loader, after D6616:

The main loader is now deployed.
Another task got opened to keep the references on the possible improvments [1]

FTR, olasd, douardda and I discussed an inconsistency in keys used in kafka, and decided to use hashes for all origin/visits/visit statuses; and doing the same for ext metadata in both kafka and the DB solves the issue about defining unicity.

@rdicosmo a full example of what?

The suggestion was to have extrinsic metadata on directories that come from a deposit of a bundle (e.g. .tar.gz or .zip file coming from HAL), instead of on a synthetic revision as is currently the case, so they can be accessed knowing the hash of the directory (which is an intrinsic id).

Alternatively, we could keep writing the metadata on revision/releases, and use the provenance service (when it's ready) to find them from a directory SWHID. What do you think?

I'm currently using the following regex to filter the exposed urls .tar.gz$|.zip$|tar.bz2$|.tbz$|.tar.xz$|.tgz$|.tar$ but I'm pretty sure it could be improved.

If that ever happens again (I don't expect it but I have been wrong in the
past), we will have a logged exception with some context.