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.