Added sketch for HTTP load balancer

I agree that there is something wrong. Not sure if this mix of sync and async is good; keep in mind that even a hostname can be resolved synchronously (e.g. if in `/etc/hosts` or in cache), for example:

1. if an `/etc/hosts` entry points to broadcast address the `connect` will fail synchronously unless `SO_BROADCAST` is set.

2. some failures are not caused by the name resolution itself but for example interface down `ENETDOWN`, no route to network `ENETUNREACH`, etc. There might also be some subtle differences between platforms in exactly which errors are returned from a `connect` to an async sockets.

To one extreme `ns_connect` could even return `void` and let all the checks be done in the handler, and avoid users keeping a pointer to the `nc` since owned by the manager and will be freed upon close.

We currently use the returned `nc` to:

1. set user_data and flags (can be done with `ns_connect_opt`)
2. send initial request (doesn't work with UDP though).
3. quickly link that new connection with another connection (through it's user_data), but this could also be done through the handler since the opposite has to be done in the new connection's close anyways. 

I still think it would be more useful to do all the error checks in the handler's `NS_CONNECT` or a `NS_CREATE` falling through the `NS_CONNECT` case (also for UDP which lacks a `NS_CONNECT` ?).