Video files buffer for extended periods of time, even while IPFS node shows outbound traffic

#### Type:
Bug

#### Description:
Issue #4085 brought up the idea of being able to more effectively handle streaming/partial-reading of content fetched through the HTTP interface, and was marked as resolved due to the `ifps cat` command getting both an `--offset` ([pull request #4538](https://github.com/ipfs/go-ipfs/pull/4538)) and `--length` ([merge](https://github.com/ipfs/go-ipfs/commit/153bb681300cc98e4646179d8d7ac9b1c34197cc)) flags.

Currently the HTTP interface uses the built in Golang `http.serveContent()` method, which should be properly parsing `Range` HTTP headers and only returns the content in the range the client requested. However, when resolving an HTTP request to get file contents of a very large video file that the node has not already got cached, the amount of time spent loading the video from another node seems to be much higher than is needed based on the outbound traffic of the hosting node.

Tested using my own local IPFS node with a video file that I created but does not have a lot of traffic (typically my node has 100KB or less outbound traffic). When accessing that video file through the `gateway.ipfs.io` node or the `cloudflare-ipfs.com` node via a current Chrome browser, Chrome detects it's a video file and includes a `Range` header in the request to get the file data. On my local IPFS node's dashboard, I can see data start to flow out:


But even after 30+ seconds of high data output, the video hasn't started playing yet. It seems something is either requesting the data out-of-order (the data flowing out of my local IPFS node is data blocks for later on in the movie, not the immediately-needed data blocks), or something else is causing delays in assembling/chunking the video data stream. My local IPFS node is connected via wired ethernet to my 300 MB fiber network connection, and shows it's connected to over 200 nodes in the IPFS network, so the network connection on this end shouldn't be the bottleneck.