pf: tests: Introduce wait_for_process()

[jlduran]

Summary

Introduce a new function that waits for processes to start with a
configurable timeout and interval. By default, it sleeps for 1 second
intervals for up to 30 seconds waiting for a process to start.

It tries to address sporadic failures in test pflog:rdr_action which may
be caused by an insufficient sleep time during tcpdump startup. The new
function provides reliable process detection with configurable
parameters for different timing requirements.

The implementation uses pgrep to detect running processes and includes
proper timeout handling to prevent indefinite waiting, as well as an
optional jail parameter. There are many "sleep 1" calls in the test
suite that can be replaced with this helper function.

[jlduran]

• Simplify jail processing
• Exit rather than return

[jlduran]

This might be an overkill, but I would like to know if a similar helper function could help avoid failure intermittence (flakiness) in some tests. I reproduced this test natively on a very fast aarch64 machine, and it did not fail once, comparing the output of a successful pass vs. a failed one makes me wonder if it is not sleeping enough:

For example:
Reference GOOD: https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/27610/testReport/junit/sys.netpfil.pf/pflog/rdr_action/ (galahad2.nyi.freebsd.org)
Reference BAD: https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/27611/testReport/junit/sys.netpfil.pf/pflog/rdr_action/ (galahad2.nyi.freebsd.org)

[kp]

I'm not sure this is sufficient. It is still possible for tcpdump to have started, but not gotten to the point of actually opening the pflog device.

I've had a very quick look at the tcpdump code, and I think it looks like we could potentially rely on the existence of a capture file (so -w <file>). I think that file only gets created after we've done pcap_open()/pcap_setfilter(). That'd require a bit of test-reworking though, because we'd be saving a pcap file, which we'd have to translate back to text to run the checks on.

tests/sys/netpfil/pf/pflog.sh

384

I'd keep this in. It can be useful when debugging test failures.

[jlduran]

In D54695#1249657, @kp wrote:

I'm not sure this is sufficient. It is still possible for tcpdump to have started, but not gotten to the point of actually opening the pflog device.

I've had a very quick look at the tcpdump code, and I think it looks like we could potentially rely on the existence of a capture file (so -w <file>). I think that file only gets created after we've done pcap_open()/pcap_setfilter(). That'd require a bit of test-reworking though, because we'd be saving a pcap file, which we'd have to translate back to text to run the checks on.

Ah, yes! I'll experiment -w <file> with atf_check -r instead.