Replacing rtsock with netlink also means providing similar tracing facilities,
rtsock provides route -n monitor interface, where each message can be traced to the originating PID.
This diff closes the feature gap between rtsock and netlink in that regard.
Netlink works slightly differently - as it is a generic message "broker", it calls some kernel KPIs and returns the result to the caller.
Other Netlink consumers gets notified on the changed kernel state using the relevant subsystem callbacks.
Typically, it is close to impossible to pass some data through these KPIs to enhance the notification.
This diff approaches the problem by using osd(9) to assign the relevant socket pointer ('nlp) to the per-socket taskqueue execution thread.
This change allows to recover the pointer in the aforementioned notification callbacks and extract some additional data.
Using osd(9) (and adding additional metadata) to the notification receiver comes with some additional cost attached, so this interface needs to be enabled explicitly by using a newly-created NETLINK_MSG_INFO SOL_NETLINK socket option.
The actual medatadata (which includes the originator PID) is provided via control messages. To enable extensibility, the control message data is encoded in the standard netlink(TLV-based) fashion. The list of currently-provided properties can be found in nlmsginfo_attrs.
snl(3) is extended to enable decoding of netlink messages with metadata (snl_read_message_dbg() stores the parsed structure in the provided buffer).