20x slowdown recording Firefox `SandboxBrokerTest.MultiThread*` unit tests

The Firefox GTests SandboxBrokerTest.MultiThreadOpen and SandboxBrokerTest.MultiThreadStat run 20x slower than native (constrained to one core) when being recorded with rr 5.1.0.

These are unit tests of the Linux sandbox file broker; seccomp-bpf is not involved. They construct a broker instance and send it a lot of requests from several threads at once in a tight loop, within the same process. (And they're the least unreliable reproducer we have for a mysterious intermittent bug.) For each request, a socketpair is created and one end is sent to the broker with SCM_RIGHTS to carry the response.

I'm not surprised that rr has to do nontrivial work for this, and it's probably not something a normal application would do on the critical path, but this is a lot of slowdown.

For reference, the command I've been running is MOZ_RUN_GTEST=True GTEST_FILTER=SandboxBrokerTest.MultiThread\* rr record obj-x86_64-pc-linux-gnu/dist/bin/firefox -unittest, and I'm using a non-debug build.

Reproduce the slowdown with the stated MOZ_RUN_GTEST, GTEST_FILTER, and rr record command, comparing native and recorded runs of SandboxBrokerTest.MultiThreadOpen and SandboxBrokerTest.MultiThreadStat. Trace the Linux sandbox file-broker test path and rr's handling of the socketpair and SCM_RIGHTS activity; done should include a measured explanation and a validated improvement or a documented limitation.