The same behaviour as ZEO/py does.

Just renaming.

Starting from Go1.14 defer is no longer slow:
https://golang.org/doc/go1.14#runtime

See go123@515a6d14

As promised in b65f6d0f (go/zodb: Teach ZODB/go to access ZEO (draft))
let's start to add tests for ZEO/go client.

The client is tested against ZEO/py server.
Cover handshake and Load.

Load currently fails beause in ZODB/py POSKeyError does not allow to
distinguish whether it is no object at all or object exists and its data
was not found for tid_before.

    --- FAIL: TestLoad/py (0.22s)
        zeo_test.go:217: load 0285cbacc06d3a4c:0000000000000007: returned err unexpected:
            have: /tmp/zeo273044293/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: no such object
            want: /tmp/zeo273044293/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c
        zeo_test.go:217: load 0285cbad858bf2e6:0000000000000006: returned err unexpected:
            have: /tmp/zeo273044293/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: no such object
            want: /tmp/zeo273044293/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6
        zeo_test.go:217: load 7fffffffffffffff:0000000000000006: returned err unexpected:
            have: /tmp/zeo273044293/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: no such object
            want: /tmp/zeo273044293/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6
        zeo_test.go:217: load 7fffffffffffffff:0000000000000007: returned err unexpected:
            have: /tmp/zeo273044293/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: no such object
            want: /tmp/zeo273044293/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c

Problem reported upstream:

-> https://github.com/zopefoundation/ZODB/issues/318

No need to use trailing : suffix as xerr.Contextf automatically adds one.

This is utility to load whole content of a ZODB database.

It will be useful to load data to expect from e.g. dataok.fs and feed it
as txnvOk to DrvTestLoad when verifying another storage driver.

This is utility to create X function, similar to exc.Raisif, but that
would call t.Fatal instead.

We will soon need this infrastructure to test other storage drivers.

E.g. before:

    --- FAIL: TestLoad/py (0.22s)
        zeo_test.go:217: load 0285cbacc06d3a4c:0000000000000007: returned err unexpected: /tmp/zeo484021674/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: no such object  ; want: /tmp/zeo484021674/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c
        zeo_test.go:217: load 0285cbad858bf2e6:0000000000000006: returned err unexpected: /tmp/zeo484021674/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: no such object  ; want: /tmp/zeo484021674/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6
        zeo_test.go:217: load 7fffffffffffffff:0000000000000006: returned err unexpected: /tmp/zeo484021674/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: no such object  ; want: /tmp/zeo484021674/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6
        zeo_test.go:217: load 7fffffffffffffff:0000000000000007: returned err unexpected: /tmp/zeo484021674/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: no such object  ; want: /tmp/zeo484021674/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c

After:

    --- FAIL: TestLoad/py (0.22s)
        zeo_test.go:217: load 0285cbacc06d3a4c:0000000000000007: returned err unexpected:
            have: /tmp/zeo087978981/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: no such object
            want: /tmp/zeo087978981/1.fs.zeosock: load 0285cbacc06d3a4c:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c
        zeo_test.go:217: load 0285cbad858bf2e6:0000000000000006: returned err unexpected:
            have: /tmp/zeo087978981/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: no such object
            want: /tmp/zeo087978981/1.fs.zeosock: load 0285cbad858bf2e6:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6
        zeo_test.go:217: load 7fffffffffffffff:0000000000000007: returned err unexpected:
            have: /tmp/zeo087978981/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: no such object
            want: /tmp/zeo087978981/1.fs.zeosock: load 7fffffffffffffff:0000000000000007: 0000000000000007: object was deleted @0285cbacc06d3a4c
        zeo_test.go:217: load 7fffffffffffffff:0000000000000006: returned err unexpected:
            have: /tmp/zeo087978981/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: no such object
            want: /tmp/zeo087978981/1.fs.zeosock: load 7fffffffffffffff:0000000000000006: 0000000000000006: object was deleted @0285cbad858bf2e6

We will soon need this infrastructure to test other storage drivers.

This package already provides parts of infrastructure for ZODB testing
(see e.g. 46636b16 and 7f14e2cb), and will be used as the place for such
infrastructure.

Maybe in the future we'll rename it to something like ztesting, but
leaving package name as is for now.

See go123@515a6d14

See go123@515a6d14

Provide way for users to retrieve Connection -> DB from which it was opened.
Wendelin.core 2 might need this to open a second connection given a one.

Provide way for users to go from DB -> IStorage for which it was opened.
Wendelin.core 2 needs it.

Implement "TODO defer stor.Close()" that was sitting there in every subcommand.

Julien Muchembled notices that strictly speaking Head could return tid
that it receives during its call, not strictly as observed before the
call. In other words for which range might be returned it is like below:

           ...\\\\\\\\\\\↓      ↓////////////...
        ──────────────────────────────────────────
               <head call>      <sync call>

Fixes 151d8b79 (go/zodb: LastTid -> Sync + Head).

[1] https://github.com/zopefoundation/ZODB/pull/307#discussion_r436881665

This helps when events are printed and logged.

Paralleling nexedi/zodbtools@0b6f99da.

All test databases in */testdata/ stay as before bit-to-bit the same.

The only change is extra LF that is appended to end of 1.zdump.pyok due
to nexedi/zodbtools@624aeb09.

Correspondingly fix dump on zodbtools/go side.

The only update comes from

b@8c9698d6

Rerun `go generate` for this package. Updates come due to updated
`stringer`. zproto-marshal.go stays the same.

When trying to regenerate zproto-marshal.go on a fresh go workspace I
got:

    (neo) (z-dev) (g.env) kirr@deco:~/src/neo/src/lab.nexedi.com/kirr/neo/go/neo/proto$ go generate
    typecheck: ../../zodb/zodb.go:174:2: could not import lab.nexedi.com/kirr/go123/mem (can't find import: "lab.nexedi.com/kirr/go123/mem")
    exit status 1
    proto.go:57: running "sh": exit status 1

Digging around a bit this turned out to be due to that
importer.Default() is using packages in only binary installed form:

    https://github.com/golang/go/issues/19334#issuecomment-283430322
    https://github.com/golang/go/issues/11415

Fix it by using "source" importer which always looks at sources.

(zproto-marshal.go stays unchanged after `go generate` rerun)

So that Go1.13 and golang.org/x/xerrors understand the wrapping:
https://blog.golang.org/go1.13-errors

Preserve Cause for compatibility with github.com/pkg/errors.

This allows to use proper btree.Node type - not just zodb.IPersistent -
in places which expects a tree node.

More comments, typos, ...

If cache control changes, all objects needs to go through new cache
control as what was e.g. pinned before could be in other class
from the point of view of new cache control.

Tests pending...

We already have LiveCacheControl and policy to keep object state in live
cache. However that state is currently kept only until the object is
present in the cache, and the object is there currently only until there
are live pointers to the object from anywhere. If all such pointers go
away, LiveCache currently discards the object.

Add a way (PCachePinObject) to tell live cache that it must retain an
object even if there are no other pointers to it. This is needed for
Wendelin.core which semantically relies on some objects to be present in
live cache, even if in ghost state, for propagating ZODB invalidations
into OS pagecache:

https://lab.nexedi.com/kirr/wendelin.core/blob/000bf16359/wcfs/wcfs.go#L245

For symmetry add a way (PCacheDropObject) to tell live cache that it
must not retain an object. This makes sense for objects that are read in
large only once to avoid needlessly evicting all other objects while
making the room for what won't be soon used again.

For completeness add also a way (PCacheDropState) to tell live cache
that the state of this object should not be cached. This can make sense
even for objects that are pinned: for example Wendelin.core pins ZBlk
objects to rely on volatile metadata it attaches to them, but have to
drop ZBlk state that was loaded from database: that state is propagated
to be cached in OS pagecache, and keeping it also in ZODB live cache
would just waste RAM.

Finally add test to cover LiveCache/LiveCacheControl functionality in
detail.

We are going to rework LiveCache to support both retaining objects in
cache even though if all pointers to them went away (currently such
objects disappear from cache), and to tell the cache that such and such
object should not be cached at all, e.g. not to evict all other objects
on one-time large reads.

This will be done by LiveCacheControl giving cache policy classification
for an object. Prepare for that and change

	WantEvict(obj) -> bool

to

	PCacheClassify(obj) PCachePolicy

which can give more information to LiveCache about how to handle an
object.

This is only a preparatory patch as there is neither no new
functionality nor fixes here.

We already have "testing connection" functionality in common place (was
named tPersistentDB -> now tConnection). However the functionality to
"setup and use testing database" was inside TestPersistentDB only.

Since we are going to add more tests, factor that functionality out of
TestPersistentDB into shared infrastructure that could be reused in
between tests (-> tDB).

It was printing oid instead of obj.

Provide functions to:

- set cache element
- iterate through all elements

LiveCache organization will be changed in the following patch, and it is
better to keep the knowledge about its internal structure localized.

For ZODB we always open database at storage level. Thus `zodb.Open(zurl)`
is relevant. At application level we open database creating DB from
IStorage and using DB.Open() .

Today LastTid is ambiguous: does it return locally cached last transaction ID,
or it performs round-trip to server to get more uptodate view of what has been
last committed? As the result of this ambiguity some drivers (e.g. FileStorage,
ZEO) return cached view, while other drivers (upcoming NEO, living on t branch)
was doing the full round-trip.

There are also situations where whether or not LastTid performs syncing to
server affects semantics: for example if there are two ERP5 nodes and one
node commits something into ZODB and conveys the fact that something has been
committed via another channel, the second ERP5 node should have a reliable way
to observe committed data. But currently there is no such way: on next DB.Open,
even with at=0 meaning "use latest transaction" and with opt.NoSync=false,
DB.Open uses storage.LastTid() as a way to sync and oops - for some drivers it
won't result in real synchronization and thus opened connection could
potentially have older view with not yet latest data.

To fix this ambiguity require drivers to provide Sync functionality only. That
should return ID of last transaction committed to storage data as observed from
some time _afterwards_ Sync call was made. In other words for particular
client-server case, Sync cannot return cached view of storage and has to
perform round-trip to the server.

At IStorage level we provide two entry points: Sync, to perform syncing, and
Head that returns database head (last transaction ID) as viewed by local cache
without any synchronization.

Please see changes to IStorageDriver and IStorage interfaces for details.

The rest of the changes are:

- teach zodb.storage (the IStorage implementer) to actually implement Sync/Head.
- adapt zodb.DB to perform Sync for !opt.NoSync case.
- teach FileStorage to do proper syncing instead of returning local cache.
- teach ZEO to perform "lastTransaction" RPC call for syncing instead of
  returning local cache.
- adapt the rest of the tree to interfaces change.

If we use only the rule that we keep last 10 minutes of database
history, and commits come less often than that - e.g. once per 30
minutes, on every new commit we'll be throwing away all δtail data,
which would result on completely throwing away live cache on every
DB.Open .

Add another rule to cover seldom updates spectrum so that we never throw
till empty δtail and keep at least 10 elements in δtail queue. This will
make sure that live cache is preserved even when updates to database are
seldom to come.

Tests pending...

This gives access to raw data stored in ΔTail. We'll need this in the
next commit, as well as going through raw δtail data is also generally
useful.