--lock-file doesn't wait for the lock, is this intentional?

I intermittently see `test-run.sh` fail with:

```
Unable to lock file /var/tmp/tap-test.nlbsH3/lock: Resource temporarily unavailable
```

I believe this is a race condition between the `lockf-n.py` and `bwrap` children of `test-run.sh`. If the backgrounded shell process `$childshellpid` is unlucky, its `bwrap` child will try to take the lock while one of the `lockf-n.py` processes is holding it. `bwrap` doesn't wait for the lock (`F_SETLKW`), just does a fire-and-forget attempt to take it (`F_SETLK`), so this fails.

For the test, this can be fixed by running `bwrap` in a retry loop. However, the more I think about this, the more I wonder: is this really intentional? Should `bwrap` be using `F_SETLKW` for its `--lock-file`?