link_linux: Add deserialization of IFF_RUNNING flag

[dylandreimerink]

I noticed that the decoded link flags never include net.FlagRunning. It seems deserialization logic was never added for this particular flag. Having access to the running flag is actually useful to detect when a link is in a NO-CARRIER state, which happens when a layer 1 issue occurs such as an unplugged or broken cable.

I also removed the comment since the function now deviates from the original.

[aboch]

Thank you @dylandreimerink
Please check the test failure is related

[dylandreimerink]

Hmm, it seems net.FlagRunning was added in go v1.20. But CI run go v1.17. Go v1.22 is currently the earliest supported version according to the go release policy, so would it be reasonable to bump the minimum go version?

[dylandreimerink]

I bumped the Go version, which seems to have fixed the original failure. But now we have a new one:

=== RUN   TestRuleListFiltered/IPv6/returns_rules_filtered_by_fwmark_0/0xFFFFFFFF#01
    rule_test.go:592: Expected len: 1, got: 0

        --- PASS: TestRuleListFiltered/IPv6/returns_rules_filtered_by_fwmark_0/0xFFFFFFFF (0.00s)
        --- PASS: TestRuleListFiltered/IPv6/returns_rules_filtered_by_fwmark_0x1234/0 (0.00s)
        --- FAIL: TestRuleListFiltered/IPv6/returns_rules_filtered_by_fwmark_0/0xFFFFFFFF#01 (0.00s)

Interestingly the suite contains the exact same test twice (hence the #01 at the end of the last sub-test name). Both the name, and the test case is the same: First and Second. But it is only on the second that fails.

Not sure if this is test flakyness or something the Go bump might have caused 🤔 .