Add XSKMAP for built-in program rules

[mtfriesen]

Description

Describe the purpose of and changes within this Pull Request.

We need to provide an XSKMAP object type similar to the eBPF XSKMAP type, but without taking an eBPF dependency. Additionally, the eBPF map today does not support fine-grained access control nor duplication across processes, which this implementation implicitly provides.

Resolves #1009

Testing

Do any existing tests cover this change? Are new tests needed?

Tests added.

Documentation

Is there any documentation impact for this change?

Yep, added, including new sample code.

Installation

Is there any installer impact for this change?

No.

[ProjectsByJackHe]

In the current xsk map implementation, say one process (trusted) creates the map, hands it to a less trusted process. the less trusted one inserts an af_xdp socket on every queue ID, then signals to the trusted process it can create the rule with the
xsk_redirect_map action. The trusted process creates the rule. But then the less trusted process exits early... will the rule stay in the engine? Now the map will have dangling af_xdp socket pointer?

Suppose with ref-counting, we don't have the dangling pointer issue, but then if the rule still stays within the engine, it would reference a "zombie" af_xdp socket where the only ref to the socket is the map itself. Does XDP delete the rule from the engine if the map is the only one holding the ref to the inner socket on all queue_ids?

Also, should XdpXskMapLookupcheck if the XSK is still "active" before returning it?