Better API for crate user without netlink knowledge

[cathay4t]

Current LinkHandle are assuming crate user knows how to handle netlink message by returning:

impl Stream<Item = Result<LinkMessage, Error>>

Many rust-netlink users are doing the parsing by themselves(include me at nispor project), I consider this as a duplicate efforts.

I propose we introduce new set of API for user who don't want to parse netlink message like:

impl Handle {
    pub async fn parsed_link(self) -> LinkParsedHandle {}
}

impl LinkParsedHandle {
    pub async fn get_by_name(
        &mut self,
        iface_name: &str,
    ) -> Result<LinkParsed, RtnetlinkError> {
        todo!()
    }

    pub async fn get_by_index(
        &mut self,
        iface_index: u32,
    ) -> Result<LinkParsed, RtnetlinkError> {
        todo!()
    }

    pub async fn dump(&mut self) -> Result<Vec<LinkParsed>, RtnetlinkError> {
        todo!()
    }

    pub async fn dump_by_filter(
        &mut self,
        address_family: AddressFamily,
        filter_mask: Vec<LinkExtentMask>,
    ) -> Result<Vec<LinkParsed>, RtnetlinkError> {
        todo!()
    }

    pub async fn change(
        &mut self,
        config: &LinkParsed,
    ) -> Result<(), RtnetlinkError> {
        todo!()
    }
}

#[non_exhaustive]
pub struct LinkParsed {
    pub iface_name: Option<String>,
    pub iface_index: Option<u32>,
    pub mtu: Option<u32>,
}

I have implemented this design in https://github.com/rust-netlink/nl-wireguard/blob/main/examples/set_wireguard.rs

It is much simpler than current LinkMessageBuilder workflow.

[cathay4t]

@little-dude @JohnTitor Any suggestions?

[cathay4t]

@ffmancera Any suggestions?

[JKearnsl]

@cathay4t, you are not loved 😂

[cathay4t]

Yeah, other rust-netlink maintainers are very-very-slow on messages especially this kind of dramatic changes.

Let's postpone this till we reach API 1.0 stable.

Current focus should be getting iproute-rs feature finished, so at least netlink-packet-route and rtnetlink crate can claim 1.0 stable. For me, this is not a pressing issue.