Make Uri optional when constructing requests

[rgrinberg]

Currently cohttp is hardcoded to use Uri when both creating requests and reading responses. Here are some disadvantages of that:

• You are forced to use Uri's encoding of query parameters
• We are also relying on Uri to know where to connect when making a request. This isn't so bad but it would be nice to just sidestep conduit and connect to an (ic, oc) pair.
• Parsing a path into a Uri when reading requests/responses is not always necessary so we shouldn't be doing it eagerly.

The biggest problem here is obviously the first one since there's absolutely no work arounds but the others are important too. This change is also congruent with our goal of keeping cohttp low level and flexible.

The amount of breakage this would cause should range from minimal to moderate for our users:

• Users who just access uri's from requests and responses using the record labels will need to use {Request,Response}.uri respectively
• Low level calls such as request will need an extra parameter to know where to connect to. Since the request would only have a string for the path and query parameters.

@avsm @dsheets @SGrondin thoughts?

[SGrondin]

Uri of Uri.t | Ip of Ip_addr.t * int | Pipe of ic * oc as suggested by @rgrinberg on Gitter is exactly what I need :+1: :+1: :+1:

I plan on providing both an Uri.t and an Ip_addr.t * int tuple. That way I can have strict control over address resolution, manipulation and caching while retaining the high level Uri abstractions. Best of both worlds.

Personally, this is my single most desired feature for cohttp.

[rgrinberg]

The above reference a possible type for targeting a cohttp client. Uri u would give us the current behavior.

[edwintorok]

Access to the raw request Uri would be useful in some situations (e.g. S3 sign requests using an HMAC, and you need to verify the signature on the original Uri, not a normalized variant of it). Ocsigen provides this, would be nice if Cohttp did too. The {Request,Response}.uri solution would work for me if the original Uri is also available as a string.