Ignore Errno::ENAMETOOLONG exception when exporting project uploads

What does this MR do?

This MR fixes Project Exports that fail with File name too long @ rb_sysopen - [FILTERED] error #213532 (closed)

Based on exception in #231546 (closed) it looks like there are project uploads that are attempted to be exported with filename that exceeds 255 characters.

During Project Export project uploads are exported (downloaded on local disk if object storage is used, moved to a temp location otherwise), in case of #231546 (closed) it is Error__line_784__Unsupported_feature__pthread_create___pthread_create___worker_i__1_____void___0___wo rker_fn____a_i__1______line_was_originally_pthread_create___worker__i______void___0____worker_fn___a__i________ParallelAlgorithm.handleFutureResults__SEVERE_ which fails with Errno::ENAMETOOLONG (since filename is 258 characters).

A proposed solution to this problem is to rescue such exception, ignore it and continue. This means the upload won't be present in the export, but a file with such name cannot be created on any of the operating systems AFAIK and I am not sure why a file with such name was allowed to be created in the first place. So project export will be succeeding with a missing upload, which is better than no export at all.

Another potential fix would be to always check if filename exceeds 255 characters and force change the filename to be less than 255 characters (e.g. remove overflow characters from filename to be exactly 255 chars).

Another workaround would have been to simply delete the upload in question, but it looks like GitLab does not currently offer and easy way of managing (deleting/downloading) uploads. On a self managed instance you could potentially access your object storage / local disk and remove it.

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• [-] Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team