GDCC/7527-fix-redetect

[qqmyers]

What this PR does / why we need it: For non File Stores, redetect was using the name of the temp file and it's extension (always .tmp) to determine the mimetype, and with .tmp not mapping to a known mimetype could return null as the answer (if other detect steps didn't work). This fix provides the name from the datafile in the db and sends 'application/octet-stream' if no other determination was made.

Which issue(s) this PR closes:

Closes #7527
Closes #8821

Special notes for your reviewer: Ran across this when doing other refactoring - would be good if someone who was following the issue could verify that this fixes both aspects.

Suggestions on how to test this: per the issue.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?:

Additional documentation:

[coveralls]

Coverage increased (+0.004%) to 20.052% when pulling 77eea56 on GlobalDataverseCommunityConsortium:GDCC/7527-fix-redetect into 6ca1c9d on IQSS:develop.

[landreev]

I really thought we had fixed this a while ago; but it appears we only talked about fixing it, but never got around to it. Great to see it fixed it finally.
Looks good. (To be clear, this was broken for all stores, not just the remote kind; it wasn't working with the filesystem storage either - because it was running the check on the internal, storageidentifier-based filename).

[pdurbin]

A couple questions:

• Should this PR close Bean Validation errors calling file redetect api endpoint #8821?
• If we merge this PR, should we close PR 7527 redetect api error #7631?

[landreev]

No, this PR does not close #8821.
#7631 should be closed regardless, because we decided not to merge it.
Note that #7527 was 2 issues in one: a trivial issue with the file name; and a strange, not easily-reproducible EJB rollback that happened only on some files in our prod., and on the installation that first reported it.
This PR fixes the trivial part of #7527 and we should merge it.
My #7631 fixed that too, but also contained an attempt to add the @Stateless annotation to the API bean in question, which for some unknown reason made the strange EJB issue go away. But it was determined that we didn't want to do that.

I'll check if that weird part of #7527 was still happening in our prod. If it is, it would be great to actually figure out what's going on there (should not block or delay merging this PR though).

[landreev]

Whether #8821 is in fact the same thing is as the mysterious EJB sub-issue of #7527, I'm not 100% sure, will check.

[landreev]

Can we add a null check in the next line here? - From looking at #8821, it appears that determineFileType() may return null here, for especially unrecognizable files; and that results in a constraint violation.
Sorry for asking for this while the PR is already in QA; but would be a trivial change. Thanks.

[qqmyers]

The change in FileUtil.java in this PR prevents a null return, so I think we're good?

[landreev]

Oh, of course, doh! Thanks!

[landreev]

Yes, this PR closes #8821 as well. Sorry for the extra noise.