REMOVE_ADDR support

[matttbe]

As defined in RFC8684:

If, during the lifetime of an MPTCP connection, a previously announced address becomes invalid (e.g., if the interface disappears or an IPv6 address is no longer preferred), the affected host SHOULD announce this situation so that the peer can remove subflows related to this address. Even if an address is not in use by an MPTCP connection, if it has been previously announced, an implementation SHOULD announce its removal. A host MAY also choose to announce that a valid IP address should not be used any longer -- for example, for make‑before-break session continuity.
This is achieved through the Remove Address (REMOVE_ADDR) option (Figure 13), which will remove a previously added address (or list of addresses) from a connection and terminate any subflows currently using that address.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
|     Kind      |Length = 3 + n |Subtype|(resvd)|   Address ID  | ...
+---------------+---------------+-------+-------+---------------+
                           (followed by n-1 Address IDs, if required)

Figure 13: Remove Address (REMOVE_ADDR) Option

For security purposes, if a host receives a REMOVE_ADDR option, it must ensure that the affected path or paths are no longer in use before it instigates closure. The receipt of REMOVE_ADDR SHOULD first trigger the sending of a TCP keepalive [RFC1122] on the path, and if a response is received, the path SHOULD NOT be removed. If the path is found to still be alive, the receiving host SHOULD no longer use the specified address for future connections, but it is the responsibility of the host that sent the REMOVE_ADDR to shut down the subflow. Before the address is removed, the requesting host MAY also use MP_PRIO (Section 3.3.8) to request that a path no longer be used. Typical TCP validity tests on the subflow (e.g., ensuring that sequence and ACK numbers are correct) MUST also be undertaken. An implementation can use indications of these test failures as part of intrusion detection or error logging.
The sending and receipt (if no keepalive response was received) of this message SHOULD trigger the sending of RSTs by both hosts on the affected subflow(s) (if possible), as a courtesy, to allow the cleanup of middlebox state before cleaning up any local state.
Address removal is undertaken according to the Address ID, so as to permit the use of NATs and other middleboxes that rewrite source addresses. If an Address ID is not known, the receiver will silently ignore the request.
A subflow that is still functioning MUST be closed with a FIN exchange as in regular TCP, rather than using this option. For more information, see Section 3.3.3.

https://www.rfc-editor.org/rfc/rfc8684.html#name-remove-address

If needed, new tickets can be created to track: receiver/sender side only and packetdrill support.

(Feature from the initial roadmap)

[matttbe]

@geliangtang is looking at this

[matttbe]

@geliangtang : maybe something that would be really good to have with the patches you sent is test: either with kselftests or packetdrill. Maybe it makes more sense with packetdrill but already having some tests validating that and checking we don't have regressions would be really nice if you have the opportunity to work on that :-)

[matttbe]

Implemented by @geliangtang and now on net-next, thx! → a1a3552
This ticket can then be closed!