It's still not complete though since it needs to also deal with origin_metadata.

That part has been completed with D265, D266 last week.

This leverages everything that needs to (scheduler, one-shot task).

Well, everything existed but nothing was tied together.
Now, when a deposit is saved/updated, a signal is raised.

When a signal is caught and the status is ready-for-checks, a oneshot check job task is scheduled.

That job is in charge of checking the tarball(s) and the metadata (plugged but not implemented yet).
If any error about this, the status is set to 'rejected'.
Otherwise, the status is passed to 'ready-for-load'.

Which also triggers a signal and the status is ready-for-load (meaning checks have passed successfully), a oneshot loading job task is scheduled.

That job is in charge of loading the deposit's tarballs (with associated metadata).
The resulting status is either 'success' or 'failure' depending on the result of the loading.

This is packaged and deployed (manifest included).

For my part, this is done and tested (integration tests, manual local test, even production tested, cf. sample).

As a note, it is ready since prior our internal deadline (5th december).

I need to ping back Bruno though since we did not have any feedback from him yet.