traceroute: add tests

[ivy]

Summary

add some basic tests for traceroute. this covers most of the flags we
can easily test; in some cases we use tcpdump to ensure the correct
packets are actually being sent.

to run the tests, we create three jails: one for the source host, one
for the destination host, and one to route packets betweem them. this
ensures we're actually testing traceroute across a routed network and
not just sending probe packets to a directly connected host.

no tests for traceroute6 are in this commit since the traceroute6 merge
into traceroute is in progress elsewhere.

Test Plan

traceroute_test:ipv4_baseport  ->  passed  [7.437s]
traceroute_test:ipv4_basic  ->  passed  [5.120s]
traceroute_test:ipv4_dontroute  ->  passed  [10.141s]
traceroute_test:ipv4_firsthop  ->  passed  [9.327s]
traceroute_test:ipv4_gre  ->  passed  [12.194s]
traceroute_test:ipv4_hugepacket  ->  passed  [9.958s]
traceroute_test:ipv4_icmp  ->  passed  [8.437s]
traceroute_test:ipv4_iptos  ->  passed  [6.374s]
traceroute_test:ipv4_maxhops  ->  passed  [5.461s]
traceroute_test:ipv4_nprobes  ->  passed  [4.723s]
traceroute_test:ipv4_sctp  ->  passed  [10.918s]
traceroute_test:ipv4_srcaddr  ->  passed  [7.297s]
traceroute_test:ipv4_srcinterface  ->  passed  [7.399s]
traceroute_test:ipv4_srcroute  ->  passed  [7.046s]
traceroute_test:ipv4_tcp  ->  passed  [17.785s]
traceroute_test:ipv4_udp  ->  passed  [8.638s]
traceroute_test:ipv4_udplite  ->  passed  [5.959s]
traceroute_test:ipv4_unreachable  ->  passed  [5.099s]

[jlduran]

Moved from https://github.com/freebsd/freebsd-src/pull/1652 per my request, as there is greater visibility here.

[jlduran]

If you have the cycles, I would prefer that the tests without tcptump are committed first (you can add me as Reviewed-by). And then submit the tcpdump part for review.
Note that I am not opposing to adding tcpdump to the tests. It is a great idea. It is just I'm not sure if the extra time it adds to each test is justified. Originally, the idea of the tests was to provide some level of confidence when unifying traceroute/traceroute6, and I believe the basic form (without tcpdump) achieves this.
Another option I see is that in the Reviewed-by trailer, you can add me with "(without tcpdump)".
I trust your judgement fully, so whatever option you choose to land this review will be fine by me. In the very rare event something wrong happens, we can always fix it post-commit.
Thank you!

[ivy]

In D49838#1138773, @jlduran wrote:

If you have the cycles, I would prefer that the tests without tcptump are committed first (you can add me as Reviewed-by). And then submit the tcpdump part for review. [...] It is just I'm not sure if the extra time it adds to each test is justified

i'm not refusing to do this but my initial reaction is that i'd rather not. my rationale is that to test traceroute in a useful way, we need to actually make sure it's sending the packets we asked it to, otherwise we aren't really testing anything except the argument parsing and the most basic functionality.

so if we want to split this into two (or more) commits to make it easier to review, that's absolutely fine, but if we're talking about the possibility that the non-tcpdump parts could be accepted and the tcpdump parts rejected, i don't think that makes sense and i'd like to talk about it more and come up with a solution that works for everyone before we commit any part of this.

Originally, the idea of the tests was to provide some level of confidence when unifying traceroute/traceroute6, and I believe the basic form (without tcpdump) achieves this.

well, my specific motivation was to make sure i didn't break traceroute when merging it, but that's more about why i wrote the tests now rather than the reason they exist at all, which is that traceroute is fairly complicated and easy to break (as i have found in the past :-) and therefore having tests for it seems like a good idea even if we didn't want to merge it.

i will wait to see what others say about this, i realise it is quite a lot of code to review all at once.

[adrian]

I like this. I like the tcpdump tests too; validating real world end-to-end behaviour is super valid/useful.