Allow for exceptions from tell()

Resolves #3035.

I'm not actually sure that this approach is the right one: I'm inclined to say that, when an exception is hit from `tell()`, that we may want to assume we don't know the length at all (return length 0) and use chunked-transfer encoding. That's a particularly good idea in this case, as frequently stdin has an unknown length altogether.

Thoughts on that point @sigmavirus24 and @jkbrzt?


> I'm inclined to say that, when an exception is hit from tell(), that we may want to assume we don't know the length at all (return length 0) and use chunked-transfer encoding

Exactly my thoughts :+1: 

Btw, I think `None` would be a better value to represent an unknown length. Length of zero can still be a valid/known one.


@jkbrzt That's true, it can, but in this requests we also send zero-length files via chunked-transfer encoding. This is because some files report having zero length but still have content in them: again, stdin on some platforms exhibits this behaviour.

I think we broke our fall-back logic there when we added the `tell()` code, so that makes this a regression fix. Regardless, let's switch to that approach. 


FWIW, doing things this way can cause the chunk size to be relatively small (each chunk will be one line in the example you've provided) because we naively iterate over the file, so @jkbrzt you may want to have some fancy detection logic for this case that _enables_ Nagle's algorithm. In the case of the test file here we sent about 40 tinygrams (fewer than 30 data bytes in each packet) which is not the most efficient way to use the network.

Requests could _in principle_ do this too, but it's not clear to me that that's useful in the general case, and detecting the appropriate situation might be hard. We could _try_ to do something smarter here (around line 431 in models.py we catch the problem of calling `super_len()` on generators, so we may want to consider treating `length == 0` and `length == None` differently, where `length == 0` causes us to wrap the file in a generator that issues multiple large reads rather than iterating.

Not sure how I feel about that though.


That auto-detection could live as an adapter in the toolbelt. That said, I think the better solution for httpie in this case is to do detect stdin file uploads and create a generator that iterates over larger chunks of stdin which is then passed to data, e.g., (untested pseudo-code)

``` py
if using_stdin:
    requests.post(url, data=chunk_stdin())

def chunk_stdin():
    # Set stdin to be non-blocking
    while True:
        chunk = sys.stdin.read(STDIN_CHUNK_SIZE)
        if not chunk:
            break
        yield chunk
```


This looks fine to me by the way.


@Lukasa can you add release notes for this too?


@sigmavirus24 Done. =)


I love this change. 


@kennethreitz Each time we change something from guessing a content length to just saying "chunked is fine for this", I feel like we're striking a victory for the way the web _should_ have been, rather than the status quo. 


@Lukasa Thanks for the fix! 

Btw, I think it would useful if there was a warning in the docs about that resulting TCP inefficiency of simply passing a file object you mention above. The current example is simply `data=f`.


@jkbrzt Yeah, there's probably some value in having a section in the advanced docs about TCP efficiency. Wanna write it? ;)