Previously failed ZIP exports will also fail subsequent ZIP exports

[jonas-atmire]

Describe the bug
During the ZIP export through the UI, a temporary directory is created based on the UUID of the eperson doing the export.
If that export fails because of a missing bitstream for example, that temporary directory is never cleared.
Subsequent exports will try to create that directory as well, but that will automatically fail because the directory already exists

To Reproduce
Steps to reproduce the behavior:

1. Go to a random collection you want to export, a single item is sufficient
2. Access the DB, and break the bitstream/assetstore linking. (For example by altering the internal_id)
3. Try the export, it will fail because the bitstream can't be found
4. Fix any possible issues (For example by changing the internal_id back)
5. Export again -> it will fail again, with an error like:

2024-04-24 11:38:33.504 ERROR export - 148 @ java.lang.Exception: java.lang.Exception: Directory /home/dspace/dspace/exports/saf-export-bbabd841-98f1-48f6-bb62-d54089931c15.zip/1 already exists!

Expected behavior
If a ZIP export fails in the DSpace codebase, it should either clear up the existing temporary export directory, or a subsequent export should at least not break it.

[tdonohue]

Pulling this over to the 8.0 board as this seems to be a high priority bug to fix. Needs a volunteer