support IFLA_VRF_PORT_TABLE attribute

[little-dude]

Links that belong to a VRF carry the VRF table ID in the link info. For a VRF link we already had these attributes:

LinkInfo([Kind(Vrf), Data(Vrf([TableId(10)]))])

For ports attached to a VRF we now have:

LinkInfo([Kind(Veth), PortKind(Vrf), PortData(VrfPort([TableId(10)]))])

This tells us that this veth interface belong to the VRF with table ID 10.

---

To test this:

sudo ip link add vrf-blue type vrf table 10                                                            
sudo ip link set dev vrf-blue up                                                                         
sudo ip link add veth20 type veth
sudo ip link set veth20 master vrf-blue # this link should now have the new attribute

Ref: https://github.com/torvalds/linux/blob/f2e367d6ad3bdc527c2b14e759c2f010d6b2b7a1/drivers/net/vrf.c#L1797

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 0% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 63.94%. Comparing base (3e16f9c) to head (4dbbfcf). Report is 3 commits behind head on main.

:exclamation: Current head 4dbbfcf differs from pull request most recent head a822400. Consider uploading reports for the commit a822400 to get more accurate results

Files	Patch %	Lines
src/link/link_info/info_port.rs	0.00%	10 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #98 +/- ## ========================================== - Coverage 63.97% 63.94% -0.04% ========================================== Files 140 140 Lines 8617 8528 -89 ========================================== - Hits 5513 5453 -60 + Misses 3104 3075 -29 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[little-dude]

The clippy failure is due to TryFrom which we explicitly import but that is part of the prelude in the 2021 edition. Should I fix this @cathay4t ?

[little-dude]

@cathay4t would you mind reviewing this?

[little-dude]

@cathay4t I added a test. Note that we might have a couple problemactic attributes when emitting packets, but that doesn't seem to be related to my changes, and I really don't have time to investigate further at the moment unfortunately. See the commented out part of the test.

[little-dude]

@cathay4t are you ok with merging this?

[cathay4t]

Your kernel support IPSTATS_MIB_REASM_OVERLAPS and IPSTATS_MIB_OUTPKTS but netlink-packet-route does not, hence the emitted data missed 8 bytes.

That is not related to your patch. I will fix it later.

[cathay4t]

https://github.com/rust-netlink/netlink-packet-route/issues/119 created for the FIXME.