fix: use application/octet-stream as default mimetype

[pmauduit]

Using a too clever mime-type guessing could lead to have spring try to serialize resources using Jackson before sending it to the client.

For example, if a JSON file is sent via the AttachmentsApi, then retrieving it will lead to an error, as the mimetype of the response will be preemptively set to "application/json", which will trigger Spring to (try to) use Jackson to serialize the resources, which does not make sense when the service should just be about dumping the file into the ServletResponse object.

This patch also drops the Files.probeContentType() from the Java API, which would be also too clever here.

Strategy here is to keep as dumb as possible, to avoid triggering too much cleverness from the framework.

Tests: runtime tested on dev infrastructure.

[pmauduit]

I still have the feeling that this patch is just a workaround, and something is wrong in the way we are using spring, but could not find a better option for now, after some hours skimming into the framework code.

And I still need to make sure that upstream is also affected.

[f-necas]

Seems strange indeed. I wonder if it works re-adding response.setContentLengthLong(Files.size(file.getPath())); which was removed from 4.4.9 (we now use responseHeaders.setContentLength(fileSize);).

Also eveything was set to Long here: https://github.com/geonetwork/core-geonetwork/pull/8946/files but not in AttachmentsApi.java

As this PR has been runtime tested, I can make a GN release 4.4.9-georchestra-02.

[pmauduit]

wonder if it works re-adding response.setContentLengthLong(Files.size(file.getPath())); which was removed from 4.4.9 (we now use responseHeaders.setContentLength(fileSize);).

I wonder if it has to be done from our (GN code) side, because if you ask for a partial content, then the content-length should vary, and I think it was the intent behind the rework from last august: leaving it to the framework instead.