The current position should be reported as the number of
bytes that were successfully read.

This passes on file but fails on S3 and HTTP.

Both s3 and http file handles use byte ranges to request subsequent
byte reads. Fix an issue where the requested range is past the end
of the file by catching response codes and requesting the rest of
the file where appropriate. The handles will return empty byte
string when there is nothing remaining in the file.

We have decided to change tack and use the content-range header
to determine EOF rather than forcing an additional read from
the server to trigger a 416 status code.

TextIOWrapper can call flush as part of seek, and so we have
to support the call in read-only mode.

If the server supports gzip encoding (which is the default for
urllib) the byte ranges refer to bytes in the compressed version
of the content. This can break the client because there is no
guarantee that those bytes can be uncompressed. Instead disable
the Accept-Encoding header so that the server is forced to
use the original byte range.

Rather than always contacting the server one more time and
using 416 status code to indicate EOF, instead look at the
Content-Range header to determine EOF or else use the knowledge
that the number of bytes received is less than the number
of bytes requested to indicate EOF.

Easier to understand than integers.

Just in case the reported end position is off the end of
the file.

This found a bug in S3 handle.

For now we can not pass byte range to wsgidav test server that
is wholly off the end of the file. Will add a test when upstream
is fixed.