mptcp: move mtpcp_rcv_synsent_state_process after tcp_ack

This ensures there are no data in the write queue before reaching
alloc_mpcb. It means that without TFO the SYN will be cleared from the
write_queue. We can thus remove the part where the SYN segment is moved
from the meta_sk write_queue to the master_sk write_queue.

Signed-off-by: Sebastien Barré <sebastien.barre@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: reduce fastopen cookie size

The current cookie size is set to 8 which requires 12 bytes in the SYN and
SYN+ACK. With MPTCP, we only have 8 bytes remaining. This patch therefore
reduces the size of the cookie to 4 bytes.

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: fastopen client support

This patch enables the support of fastopen in the MPTCP stack. As fastopen
sends data in the SYN this data is not covered by a DSS. However, when
receiving the SYN+ACK the client knows the number of bytes of the SYN that
were received. Mapping this data to data sequence number is therefore not
mandatory as the SYN / SYN+ACK exchange is sequential. Unacknowledged data
must however be mapped to data sequence number in order to retransmit this
data at the MPTCP-level.

To deal with middleboxes that can add or remove bytes in the SYN. We decided
to change the semantics of the relative subflow sequence number in the DSS.
It now starts at the sequence number of the first unacknowledged byte - 1.
We use -1 to have the same behavior as regular MPTCP, i.e., the first data
sent will have a ssn of 1 (as the SYN accounts for 1 byte).
(see also https://datatracker.ietf.org/doc/draft-barre-mptcp-tfo/)

To understand how remaping works here are two examples (output syntax is
from packetdrill):

1. Server only acknowledge the SYN (ex if it does not supports fastopen)

> S 0:20(20) win 29200 <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7,mp_capable a>
< S. 0:0(0) ack 1 win 5792 <mss 1460,sackOK,TS val 700 ecr 100,nop,wscale 7,mp_capable b>
> . 1:1(0) ack 1 <nop,nop,TS val 100 ecr 700,mp_capable a b, dss dack4=1>
> P. 1:21(20) ack 1 win 229 <nop,nop,TS val 150 ecr 700,dss dack4=1 dsn4=1 ssn=1 dll=20>
< . 1:1(0) ack 21 win 5792 <nop,nop,TS val 700 ecr 150,dss dack4=21>

2. Server acknowledge the SYN and the data

> S 0:20(20) win 29200 <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7,mp_capable a>
< S. 0:0(0) ack 21 win 5792 <mss 1460,sackOK,TS val 700 ecr 100,nop,wscale 7,mp_capable b>
> . 1:1(0) ack 1 <nop,nop,TS val 100 ecr 700,mp_capable a b, dss dack4=1>
write(3, ..., 1000) = 1000
> P. 21:1021(1000) ack 1 <nop,nop,TS val 100 ecr 700,dss dack4=1 dsn4=1 ssn=1 dll=1000>

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: fastopen server support

This patch enables the support of fastopen on the server side. Fastopen
creates the socket at the reception of the SYN. We performs the same in
MPTCP (i.e. creating the master/meta).

As the data received in the SYN is mapped to TCP sequence number we need
to remap them to MPTCP sequence numbers to ensure that the next call
to tcp_recvmsg will copy these data to the userspace. For this we map the
data to [IDSN - len - 1, IDSN[ where len is the number of bytes of data
and -1 is due to the fact that by default the segment contains the SYN
flag which accounts for 1 byte.

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>