Add arp/ndp tests in addition to rtsock ll tests.

[kp]

We could potentially use pft_ping.py to actually verify that the stack sets the correct MAC address on packets (and thus also check that the insertion really succeeded), but this'll catch a number of potential issues already.

[melifaro]

In D28812#645023, @kp wrote:

We could potentially use pft_ping.py to actually verify that the stack sets the correct MAC address on packets (and thus also check that the insertion really succeeded), but this'll catch a number of potential issues already.

IMHO there are multiple things worth testing:
(1) rtsock API - that's what we have in tests/sys/net/routing/test_rtsock_lladdr
(2) that actual arp ndp binaries work (as they have logic other than just sending a proper message - that's what these tests are targeting
(3) datapath actually uses these entries - partially covered in IPv4/IPv6 multipath tests, but we certainly need an explicit tests for these as well

[kp]

In D28812#645028, @melifaro wrote:

(3) datapath actually uses these entries - partially covered in IPv4/IPv6 multipath tests, but we certainly need an explicit tests for these as well

I'm in the process of adding some basic Ethernet filtering capabilities to pf. I discovered the problem because one of the tests I have for that started failing. We could potentially just consider that as a test for this. Although I've only got v4 tests, because there's not much of a difference from an Ethernet perspective.

Either way, this is a step forwards in testing our code.

(If I'm nitpicking, our shell style appears to be to put the opening { on a new line, and to not have empty lines after that.)

[melifaro]

Landed in a different fashion.