try and ensure 100% success rate even on crappy networks

Nobody has claimed this yet.

today while testing duplex http at tivoli gardens in copenhagen we had the follow success/fails when doing a `dat pull` from an ubuntu server to a client tethered to either a slow t-mobile international roaming connection or a fast danish roaming connection:
- http w/ nginx on tmobile: fail
- https w/ nginx on tmobile: success
- http w/ nginx on 3: success
- https w/ nginx on 3: success
- http w/o nginx on tmobile: success
- https w/o nginx on tmobile: success
- http w/o nginx on 3: success
- https w/o nginx on 3: success
- ssh on tmobile: success
- http w/ nginx on tmobile plus calling http request.end - success (because it wasn't duplex http)

so something involving tmobile and nginx causes duplex http to break (major WTF). this wasn't a dat bug, we made a very small test case. the fix is to use https or ssh, and not http

we are thinking if you try and pull over http we should show a warning. we could also do a self signed certificate automatically when you do `dat serve` and default to https when cloning

we also want to write a simple duplex-http-tester CLI that anyone can run to test connections

Start by reproducing the reported duplex HTTP failure using dat pull with nginx on the slow T-Mobile connection, comparing HTTP, HTTPS, SSH, and the request.end case. The issue names dat serve, cloning, and a possible duplex-http-tester CLI but no files or tests; completion is unresolved between an HTTP warning, automatic HTTPS, HTTPS-by-default cloning, and the tester.

Written by the indexing model from the issue text.