Netlink event API: add SUBFLOW_CREATED event

[matttbe]

For the moment, there is no event when a subflow has been created, only when it has been established.

If we have this situation:

• the userspace PM creates a subflow -- when the command will be available, see Add netlink command support #186 -- without specifying the src port/address.
• the subflow is never established, e.g. SYN are dropped
• the userspace is not able to destroy the subflow -- again, when the command will be available -- because the userspace doesn't have the 5-tuples.
• the userspace will see SUBFLOW_CLOSED events for unknown subflow

Solution: have a SUBFLOW_CREATED event.

[fw-strlen]

We could suppress SF_CLOSED for subflows that were never announced.
I think that for purpose of 'canceling' a subflow connect request it would make more sense to me to support
the NLM_F_ECHO flag in the 'create' api so that mptcpd learns some identifier that it can use to
terminate the connection request when it sends the appropriate create command.

[matttbe]

We could suppress SF_CLOSED for subflows that were never announced.

Indeed. For me, receiving an event for an unknown subflow is not a big deal: anyway the userspace app has to manage this case in case events are lost, the app is restarted, etc.

I think that for purpose of 'canceling' a subflow connect request it would make more sense to me to support
the NLM_F_ECHO flag in the 'create' api so that mptcpd learns some identifier that it can use to
terminate the connection request when it sends the appropriate create command.

Good point, I didn't think about that!
Will the advantage be that only the creator of the subflow will get the notification?
From what I see; the creator will not have to "block" so it seems good.

I was thinking about a new dedicated event because on the kernel side, we send the same content: the implementation is easy. And this could benefit to others, e.g. if we only have a listener (ip mptcp monitor) or if the subflow has been created by one part the events are processed by another entity. We can have two channels of communications: one for the events and one for the commands (and their ACKs): one part is in charge or managing new events and the other side is in charge of sending commands and wait for ACK. Not sure it is the proper way to do such thing.

[VenkateswaranJ]

@matttbe what do you mean by when the command will be available? how does the user's space know whether the command is available or not?

[matttbe]

@VenkateswaranJ it was just to say that this task depends on #186 (now done).

The userspace can know if a command is supported by trying it and check the return code.