Without specifying the content type the http puts have the content type
"application/x-www-form-urlencoded" by default.

This can lead to the caldecott web app trying to parse the data as
a querry string.

I'm guessing there are safety checks that are built in to try to prevent
parsing binary data in rack which makes this work most of the time.

However if the data being sent is over the max rack form size or the binary
data is similar to a http post submit the tcp tunneling will fail with an
error similar to the below on the server side.

"!! Unexpected error while processing request rails ....."

By specifying a binary content type this parsing doesn't take place.
MAX_RETRIES of 10 isn't a really good idea because if doing large restores over caldecott you could easily
get 10 timeouts in a row from the server before the server needs to send any data.
Fixing deadlocks with caldecott tunneling.

The caldecott server can send more than the BUFFER_SIZE due to the way it is written.
It only stops receiving data if more than 1mb (currently) is pulled. So it can be just over
1mb.

The current code passes the 1mb to the client application then goes to read from the tunnel again
with data still in the buffer. If the client application is waiting for this data before sending a response
and the server is waiting for the response we get into a dead lock.

Lets makes sure we have sent all data in the buffer before we try to read again.
- Remove any references to MAX_RETRIES
- Update test cases so they don't just repeat up to the MAX_RETRIES as
that functionality as now been removed. They should repeat up to 5 times
and the http calls will then succeed.
- Add a test case for sending 1mb of data from the tunnel to the local
server.