Refactor Import/Export worker model
After #54084 is done, we'll get more timeouts since more batching and frequent DB commits would reduce the memory footprint but slow down the imports/exports.
We should try to logically separate the Import/Export into specific workers. For this, we should consider:
- A worker for importing the repo
- A worker for uploads
- Many workers for the DB
For the DB-side, we should be careful with the approach as there could be dependent models. We'll need to logically separate these workers so there's no conflict and making sure the order does not matter so we can run them concurrently... This may potentially introduce a new configuration or a spec that would detect conflicts.
A manage worker will have to coordinate the different parts and set the import to "done" when everything finishes.
We should also cope with retrying mechanisms (not currently working).