chain: read the hook device attributes back

[MemorManeo]

AddChain marshals NFTA_HOOK_DEV, but hookFromMsg reads only the hook number and the priority, so a chain read back from the kernel never carries the device its hook is attached to. An ingress or egress chain is then indistinguishable from one attached to every device.

This reads NFTA_HOOK_DEV and the NFTA_HOOK_DEVS list, and adds Chain.Devices for the multi-device case a single string cannot represent (devices = { eth0, eth1 }). AddChain marshals the list when one is set, so such a chain now round-trips. Setting Device alone behaves exactly as before, so this is additive for existing callers.

NFTA_HOOK_DEVS and NFTA_DEVICE_NAME are not exported by golang.org/x/sys/unix, so their values are declared locally with the kernel enum they come from named alongside.

Testing

Three tests cover the single-device attribute, the nested list, and a chain with no device at all. The existing suite passes unchanged.

Why

Found while writing a tool that audits which ports a host exposes by reading its ruleset over netlink. Without the device, an ingress chain has to be treated as seeing every packet, which makes every verdict about such a host unusable. The workaround was a second NFT_MSG_GETCHAIN dump alongside this library's own, purely to recover an attribute the library had already read and discarded, which is the kind of thing that belongs upstream instead.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.