Per-vhost listening addresses

[krizhanovsky]

Currently we can open many listening sockets (see the wiki), but all vhosts will be services on all the addresses. It must be possible to specify per-vhost listening addresses. All vhosts w/o explicit listening address must be serviced on the global listening address as now.

The listening addresses reconfiguration must be zero-downtime.

[vankoven]

We can also allow to bind very specific http_chain to a listening address, so only subset of vhosts would be serviced via it. E.g.:

listen 80 chain=global_chain;
listen 8080 chain=customer_1_chain;

http_chain global_chain {
    match hdr "Host" == ''a.com" -> vhost_a;
    match hdr "Host" == ''b.com" -> vhost_b;
    ...
    match hdr "Host" == ''z.com" -> vhost_z;
    -> block;
}

http_chain global_chain {
    match hdr "Host" == ''i.com" -> vhost_i;
    match hdr "Host" == ''j.com" -> vhost_j;
    -> block;
}

This can be very generic solution and might be handy in some installations. Also http_chain rules allows to set/read skb marks, so anyway we have to support per-vhost chain rules.

[krizhanovsky]

Crucial for a CDN setup.

It's impossible to keep different protocols on the same listening address and port, i.e. following configuration is invalid

listen :443 proto=https;
listen :443 proto=h2;

However, with HTTP/3 following configuration is valid since there are TCP and UDP ports:

listen :443 proto=h2;
listen :443 proto=h3;

I.e. we need not only information about IP and port, but also about the protocol (TCP/UDP or h2/h3) and this is the business for L3/L4 firewall like IPtables to care about low level networking. Also the current HTTPtables implement AND with different chain and OR with rules within the same chain.

Thus, the task is only in making listen option be configurable on the fly. Please also update https://github.com/tempesta-tech/tempesta/wiki/On-the-fly-Reconfiguration#on-the-fly-configuration-possibilities and https://github.com/tempesta-tech/tempesta/wiki/Handling-clients#listening-address .

The approach produces a lot of boilerplate configuration. Instead of adding only one listen directive to a vhost, we also need to:

1. generate an iptables rule to set mark for the listening address
2. create a chain for the new listener
   In general, a vhost has 2 HTTPtables chains for listening mark and matching Host header.

Instead of writing the new code in C for this particular usability improvement we can solve this with:

1. cfg_upd daemon from Full/per-vhost dynamic (re)configuration: gRPC API #67 can do any conversions of user-friendly configuration into the low level IPtables and HTTPtables logic
2. we should rework HTTPtables with HTTPtables migration to eBPF #102 into a low-level mechanism, see HTTPtables migration to eBPF #102 (comment) . For this design we should keep basic HTTPtables operators simple to rework them in eBPF control structures.

Tests for the issue is #716