in-kernel PM: store received ADD_ADDR

[matttbe]

Currently, upon the reception of an ADD_ADDR, new subflows are potentially created (depending on the limits), and accepted ADD_ADDR are somehow stored in the 'conn_list'. If we want to browse the list of accepted ADD_ADDR, the PM can iterate over the list of subflows, and compare addresses.

There are some limits:

• if subflows are removed from the list from different reasons (error, closed by the other peer, etc.), we potentially lose the linked address
• if the subflow is no longer in the conn_list, some events might no longer trigger the expected action, e.g. the add_addr_accepted counter will not be decremented upon the reception of an RM_ADDR → it might be needed to do a series of actions also when subflows are removed from the conn_list.
• if also means the PM will not be able to create future subflows using the linked address

(Also note that in the conn_list, we could have more than one subflow using the same remote address, adding a bit more complexity.)

Idea: storing received ADD_ADDR (in a list?) instead of relying on the conn_list:

• It would ease remote addresses managements: we store what we received, we can mark the ones being accepted, we can remote an item from the list when a RM_ADDR is removed (fixing the issue with the add_addr_accepted counter), etc.
• This should simplify the code in pm_netlink. Iterating over this list instead of the conn_list.

Linked to mptcp: update add_addr_accepted and accept_add after subflow added patch.

[matttbe]

@pabeni : from what I understood, when you designed the in-kernel PM, you didn't want to create a list of received ADD_ADDR, probably because it was enough to rely on the conn_list.

Now that new(?) limits have been listed, do you think adding a new list would be OK?