If we keep it activated, there could be a problem at Resync time - if
Resync sees that old zhead.At is outside of DB.δtail coverage it will
invalidate all zhead.cache objects, not only changed objects. That means
that even non-changed and being kept active ZBigFile will be invalidated
and oops - PInvalidate will panic.

We could avoid it via deactivating all ZBigFiles on each transaction
update, but that can be too expensive if there are many ZBigFiles.

We could avoid the problem another way - add to ZODB/go API to request
that DB.δtail covers particular connection. That in turn would mean we
have to also extend ZODB/go API to release connection from affecting DB
via such constraint. Even if first step could be done via e.g. another
flag, the second step - release - is not very clear - we already have
connection "release" on transaction completion and adding e.g.
conn.Close() in addition to that would be ambiguous for users.
Also, if wcfs is slow to process invalidations for some reason,
such constraint would mean DB.δtail would ↑ indefinitely.

-> we can solve the problem in another way: don't keep ZBigFile always
activated and just do activation/deactivation as if working with ZODB
objects regularly. This does not add any complications to code flow and
from the performance point of view we can practically avoid the slowdown
by teaching zodbCacheControl to also pin ZBigFile in live cache.

If we don't early-disable it, we can see a situation where when
handling invalidations wcfs calls open("@revX/bigfile/...") to upload
cache data there, go runtime tries to use epoll on that fd, and it gets
stuck as described in the commit referenced in comments.

In particular the deadlock was easy to trigger with nproc=1 environment
(either a VM with 1 cpu, or e.g. under `taskset -c 0`)

Bug reported by @romain.

* master:
  t/qemu-runlinux: Mount bpf and fusectl filesystems
  t/qemu-runlinux: Issue terminal resize before running program
  t/qemu-runlinux: Don't propagate $TERM in graphics mode

bpf is needed for tools like bpftrace.
fusectl is needed to observe things like /sys/fs/fuse/connections/X/waiting.

Else program inside sees default terminal settings to be 80x25,
while after the patch it sees correct settings.

Still something is not completely right with terminal settings, as e.g.
vsplit is not working correctly in vim (vertical ruler is not straight).

Graphics mode runs in another window with its own terminal emulation,
so propagating e.g. TERM=xterm to where it is emulated as TERM=linux is
not correct.