There was some debug logging mixed in with some error handling on PUTs
that was relying on a very specific edge would only encounter a set of
backend responses that included the expected set of headers to diagnoise
the failure.
But the backend responses may not always have the expected headers.
The proxy debug logging should be more robust to missing headers.
It's a little hard to follow, but if you look `_connect_put_node` in
swift.proxy.controller.obj - you'll see that only a few connections can
make their way out of the initial put connection handling with a "resp"
attribute that is not None. In the happy path (e.g. 100-Continue) it's
explictly set to None, and in most errors (Timeout, 503, 413, etc) a new
connection will be established to the next node in the node iter.
Some status code will however allow a conn to be returned for validation
in `_check_failure_put_connections`, i.e.
* 2XX (e.g. 0-byte PUT would not send Expect 100-Continue)
* 409 - Conflict with another timestamp
* 412 - If-None-Match that encounters another object
... so I added tests for those - fixing a TypeError along the way.
Change-Id: Ibdad5a90fa14ce62d081e6aaf40aacfca31b94d2
7071762d36