fw/sock: [WIP] Do not initiate new connection

[s0nx]

if MSS is too low

[s0nx]

Different approach to solve low MSS values in #1703 (as opposed to the solution in #1842):

1. When loading Tempesta and establishing connections to all backend servers within server group, check for current MSS value right after the connection establishment.
   This can be done inside ss_tcp_state_change() if sk->sk_state == TCP_ESTABLISHED.
   If MSS is too low, drop the connection(s) to the particular server and failover to the remaining server connections.
   Also, in this case we shouldn't probably make any attempts to reconnect.
2. We should probably react somehow on MTU change events. It's not really easy because there exist no persistent struct sock <---> struct net_device mapping in kernel.
   The only way to get to underlying net_device is via struct dst_entry of the socket. This dst_entry might change at any moment though as a result of altering routing tables, device going down and so on.
3. Since MTU and consequently MSS might change at any moment as well, we should perform the sk_buff headroom check before forwarding SKBs from backend to the client.
   Consider this scenario:
   • we get client request, perform http/2 -> http/1 transformation and forward it to backend. While doing so, the MTU of the link between Tempesta and backend is 'regular', e.g. 1500.
   • right after receiving the request from Tempesta, an MTU was changed to some low value, e.g. 80.
   • we receive the response from backend, but since the MTU has changed, all the received SKBs are highly fragmented and the headroom is not sufficient to accommodate transport headers.
     We can either check for MSS in ss_tcp_data_ready() and purge the queue with these SKBs, sending the error response to client or we can print a warning and perform the transformation the way it's done in Fix various problems reported in #1703 #1842.

For client side connections:

1. When configured to work in http/1 mode, we can detect low MSS during connection establishment in ss_tcp_state_change() and send RST to client. We have to do this due to the fact that in http/1 mode we do reuse the same SKBs when forwarding request to backend.
2. For http/2 mode, we shouldn't really care about client side low MTU links, since we would allocate SKBs by ourselves.