HTTP frameworks benchmark focused on D libraries

[tchaloupka]

Hi,
as there are two more HTTP server implementations:

* 
[Serverino](https://forum.dlang.org/thread/bqsatbwjtoobpbzxdpkf@forum.dlang.org)
* 
[Archttp](https://forum.dlang.org/thread/jckjrgnmgsulewnrefpr@forum.dlang.org)

It was time to update some numbers!

Last results can be seen 
[here](https://github.com/tchaloupka/httpbench#multi-core-results) - it's a lot of numbers..

Some notes:

* I've updated all frameworks and compilers to latest versions
* tests has been run on the same host but separated using VMs 
(for workload generator and servers) with pinned CPUs (so they 
don't interfere each other)
* as I have "only" 16 available threads to be used and in 12 vs 4 
CPUs scenario wrk saturated all 12 CPUs, I had to switch it to 
14/2 CPUs to give wrk some space
* virtio bridged network between VMs
* `Archttp` have some problem with only 2 CPUs so it's included 
only in the first test (it was ok with 4 CPUs and was cca 2x 
faster than `hunt-web`)
* `Serverino` is set to use same number of processes as are CPUs 
(leaving it to default was slower so I kept it set like that)

One may notice some strange `adio-http` it the results. Well, 
it's a WIP framework (`adio` as an "async dlang I/O"), that is 
not public (yet). It has some design goals (due to it's  targeted 
usage), that some can prefer and some won't like at all:

* `betterC` - so no GC, no delegates, no classes (D ones), no 
exceptions, etc.
   * should be possible later to work with full D too, but it's 
easier to go from `betterC` to full D than other way around and 
is not in the focus now
* linux as an only target atm.
* `epoll` and `io_uring` async I/O api backends (can be extended 
with `IOCP` or `Kqueue`, but linux is main target now)
* performance, simplicity, safety in this order (and yes with 
`betterC` there are many pointers, function callbacks, manual 
memory management, etc. - thanks for `asan` ldc team ;-))
* middleware support - one can setup router with ie request 
logger, gzip, auth middlewares easily (REST API middleware would 
be one of them)
* can be used with just callbacks or combined with fibers (http 
server itself is fibers only as it would be a callback hell 
otherwise)
* each async operation can be set with timeout to simplify usage

It doesn't use any "hacks" in the benchmark. Just a real HTTP 
parser, simple path router, real headers writing, real `Date` 
header, etc. But has tuned parameters (no timeouts set - which 
others doesn't use too).
It'll be released when API settles a bit and real usage with 
sockets, websockets, http clients, REST API, etc. would be 
possible.