Fix incorrect responses for HEAD /audio/<id>/stream

Without this fix my Samsung Soundbar (HW-Q80R) fails to play using DLNA
and returns "Error: Resource not found (716)" instead.

I had a look on tcpdump network logs between Jellyfin and the soundbar
and noticed that the device performs a HEAD request for the media before
responding to the DLNA UPNP control request from Jellyfin (or BubbleUPNP
Android App).

Jellyfin retuns 204 No Content response, which is unusual.  Common web
servers generally return 200 OK if the GET would return content, and
this is not-very-clearly suggested [in HTTP
spec](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1)

The other patch is to ensure, that invalid Content-Length: 0 is not
returned with the HEAD response in the streaming case.

I think in both cases we still don't return the same headers with HEAD
as with GET (e.g. Content-Length or Accept-Ranges), but at least we
don't return anything misleading.

Jellyfin.Api/Helpers/FileStreamResponseHelpers.cs

@@ -46,7 +46,8 @@ namespace Jellyfin.Api.Helpers
 
             if (isHeadRequest)
             {
-                return new FileContentResult(Array.Empty<byte>(), contentType);
+                httpContext.Response.Headers[HeaderNames.ContentType] = contentType;
+                return new OkResult();
             }
 
             return new FileStreamResult(await response.Content.ReadAsStreamAsync(cancellationToken).ConfigureAwait(false), contentType);
@@ -71,7 +72,7 @@ namespace Jellyfin.Api.Helpers
             // if the request is a head request, return a NoContent result with the same headers as it would with a GET request
             if (isHeadRequest)
             {
-                return new NoContentResult();
+                return new OkResult();
             }
 
             return new PhysicalFileResult(path, contentType) { EnableRangeProcessing = true };