If the connection requests a large MSS > 16k, for example to exploit a
large MTU, then writes block because available space is believed to be 0.

Consider UTX.available:
```
let available t =
    let a = Int32.sub t.max_size t.bufbytes in
    match a < (Int32.of_int (Window.tx_mss t.wnd)) with
    | true -> 0l
    | false -> a
```
Initially max_size = 16k (hardcoded in flow.ml) and bufbytes = 0,
so a = 16k (meaning 16k space is free in the buffer).

If the free space (a) is less than an MSS, we return 0 and the connection stalls.

I think the assumption is that the UTX can buffer at least 2*MSS worth of
data so that when the free space (a) is less than an MSS, the buffer already
contains an MSS worth of data to transmit to make progress.

Bump the user buffer size to 128k which is 2x a 64k MSS (where 64k is the max
value of the 16-bit MSS option).

This might need rethinking if we support segmentation offload because we might
see even bigger segments.

Signed-off-by: David Scott <dave@recoil.org>