Guard against nil tempfiles in MARC export job

[jazairi]

Why these changes are being introduced:

If a tempfile has already been closed and unlinked, the ensure
block in MarcExportJob#perform will throw an error.

Relevant ticket(s):

• https://mitlibraries.atlassian.net/browse/ETD-546

How this addresses that need:

This checks if the tempfile exists before attempting to close it.

Side effects of this change:

Adds rubyzip to gemfile. Rubyzip is already used by other gems, and
it can be called in local development, but bootsnap seems to require
it to be loaded explicitly.

Developer

• All new ENV is documented in README
• All new ENV has been added to Heroku Pipeline, Staging and Prod
• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• There are appropriate tests covering any new functionality
• The documentation has been updated or is unnecessary
• The changes have been verified
• New dependencies are appropriate or there were no changes

Requires database migrations?

NO

Includes new or updated dependencies?

YES (sort of -- we are explicitly adding rubygems to the gemfile, whereas it was previously installed by other dependencies)

[coveralls]

Coverage increased (+0.002%) to 97.09% when pulling a0caeca on ETD-546-alma-oclc-export into ecc77d1 on main.

[jazairi]

@JPrevost Interestingly, this didn't come up in local testing. I'm planning to create some dummy theses in the PR build to confirm that this fixes the problem.

[jazairi]

@JPrevost Just confirmed that this is ready for review after much ado. If you'd like to test yourself, I created two fake-published theses that should export successfully using the MarcExportJob. I haven't yet run the full DspacePublicationResultsJob but I will probably do that before merging. (I ran into issues with the pipeline handles, which are fixed now.)