lsof on FreeBSD might emit warnings and fail component_test_cmake_out_of_source

[gilles-peskine-arm]

In Mbed TLS 2.x, component_test_cmake_out_of_source in tests/scripts/all.sh runs a test case from tests/ssl-opt.sh and checks that there are no error messages. This has been broken for a while due to an incorrect dependency in ssl-opt.sh: the test case only runs if requires_openssl_with_fallback_scsv, which depends on the version of openssl. We never noticed until now, but the test case is skipped on our FreeBSD CI because its openssl is too recent — it's still running as expected on Linux because we run it with an older openssl.

#5730 fixes the dependency of the test case, and so it now runs on FreeBSD as expected. But all.sh test_cmake_out_of_source then fails on Arm FreeBSD instances due to a warning message from lsof. Seen in https://jenkins-mbedtls.oss.arm.com/blue/organizations/jenkins/mbed-tls-pr-merge/detail/PR-5730-merge/3/pipeline/420:

Fallback SCSV: beginning of list ....................................... PASS
------------------------------------------------------------------------
PASSED (1 / 1 tests (0 skipped))
lsof: WARNING: compiled for FreeBSD release 12.2-RELEASE-p10; this is 12.2-RELEASE-p7.
lsof: WARNING: access /home/ec2-user/.lsof_freebsd: No such file or directory
lsof: WARNING: created device cache file: /home/ec2-user/.lsof_freebsd
^^^^test_cmake_out_of_source: test: cmake 'out-of-source' build: [ ! -s ssl-opt.err ] -> 1^^^^

[gilles-peskine-arm]

Tentatively worked around in fd426fa (#5730) by using lsof -t, which suppresses warnings.

[gilles-peskine-arm]

I tried my FreeBSD VM that has the same FreeBSD version but not necessarily exactly the same configuration and the same version of ports, and it has the same issue with lsof warning messages. So this isn't just some oddity in Arm's setup, it's a problem with FreeBSD (I guess, with the lsof port, or with it not being updated exactly at the same time as the FreeBSD kernel). Therefore it does make sense to work around it in the test scripts, and not make it the problem of the infrastructure. Hence I consider the workaround in #5730 to resolve the issue.