HTTP storage protocol should not support requests beyond the end of the share

[itamarst]

Currently requests beyond the end of the share result in truncated result. This is a weird thing to do from an HTTP perspective, and I suspect is only done because Foolscap maps directly to function calls; more structured information in a HTTP response ought to make it unnecessary. So:

1. The HTTP protocol will not support this; reading beyond the end will result in HTTP error.
2. The HTTP protocol will grow HEAD endpoints for mutable and immutables shares to get their length.
3. Given the length of a share, the IStorageServer emulation layer can emulate this behavior by truncating requests to the actual length of the share. If a mutable is written half-way this in theory can result in error, but oh well.

[itamarst]

After further thought, returning truncated responses is probably fine. However, we still need to ensure the response headers are correct, which is _not_ the case now.

[itamarst]

1. Address all TODOs mentioning 3907, using new proposed design where truncated responses are acceptable so long as they are internally consistent.
2. The client should validate the length of response matches what is claimed in the Content-Range header. If it doesn't, this is either a bug, or in the case of mutables suggests a write happened while reading. Either way the data should be thrown away.

[GitHub <noreply@…>]

In 26f15f4/trunk:

Merge pull request #1204 from tahoe-lafs/3907-http-response-lengths

Improved HTTP response length handling

Fixes ticket:3907