We can return to migrating previous block by amending the condition when
we can do so: if that previous block is also modified by current
transaction, then migrating it is ok without breaking the invariant.

Also rework append criteria to be really adding data to tail of the file
instead of growing data of a block somewhere in the middle of the file.
This should prevent false-positive ZBlk0 activations.

'ZBlk0' and 'ZBlk1' always only change the block that's explicitly altered,
while zblk format 'auto' may also alter blocks different to the explicitly
changed blocks. In other words, as @kirr noted in nexedi/wendelin.core!20 (comment 198863),
format 'auto' break the invariant

    "transaction changes ZBlk objects only for modified blocks of array" [1]

Breaking this invariant leads to two failed WCFS tests -
'test_wcfs_crash_old_data' and 'test_wcfs_watch_vs_access'.

As suggested in nexedi/wendelin.core!20 (comment 198863)
instead of patching tests, we rather try not to break this invariant
with format 'auto'. This is exactly what this patch does. Instead of
changing the previously filled up block, we immediately change a blocks
format if we can assume that it is already full.

[1] nexedi/wendelin.core!20 (comment 198863)

nexedi/wendelin.core!20 (comment 198341)

Take suggestions from Levin into account (nexedi/wendelin.core!20 (comment 198330)) :

    1. appending can be False, even though we are appending (misleading name).
    2. A big append uses ZBlk0 due to an if clause 25 lines later (logic is a bit far).
    3. in the previous version it could happen that if a block was filled up
       with small appends (ZBlk1), it wasn't transformed to ZBlk0 in case
       the next block would be filled up with only one big append.
    4. Regarding the actual algorithm, I wonder, why do we only use ZBlk0
       for big appends in case it's the first append of a new ZBlk? Couldn't
       we generally say it's ok to use ZBlk0 in case of big appends?

All these notes are valid. The problem comes from misleadin semantic
attached to 'appending' name. From the name it indicates only appending,
but sometimes we want to attach 'small' meaning to it and we were not
doing it universally.

-> Fix the problem by splitting 'appending' and 'small' into separate
   flags so that there is no room for confusion.

-> Rework the flow of code so that all cases that related to appending
   are under one branch.

-> Also optimize ndelta computation - when done in plain python just
   this part was taking a lot of time as timing for initial writeup
   showed:

     writeup with ZBlk0: ~20-25s
     writeup with ZBlk1: ~20-30s
     writeup with auto:  was ~ 120s

   now, after switching to numpy for ndelta computation, whole runtime
   with 'auto' is taking ~ 35s. The whole runtime, if I observe
   benchmark execution correctly, is dominated by database writeup.

Try to keep documented promise that

	The heuristic 'auto' should behave as good as ZBlk0 in case of wide changes

Previously the heuristic code would use ZBlk0 only in append case after
switching previously filled-up block to ZBlk0, and the case of arbitrary
changes were unconditionally using ZBlk1.

Now we see if the append is small and use ZBlk1 only then. If the append
is big, or if the change is itself is big - we use ZBlk0.

This should restore documented behaviour that heuristic behaves as good
as ZBlk0 in case of wide changes.

TODO update benchmark/test to cover this case.

Use type objects instead of strings to refer to formats because with
strings scattered here and there it is very easy to cause misbehaviour
due to e.g. a typo. With referering to objects by their name, a type is
automatically caught either at runtime, or statically via e.g. pyflakes.

Rename 'h' to 'auto' and update module documentation accoring to
introduced heuristic. The rename is done because 'h' is not
descriptive, while 'auto' is more descriptive.

Fix tests that started to fail with e.g,:

    bigarray/tests/test_arrayzodb.py::test_zbigarray FAILED

    ===================================================================== FAILURES =====================================================================
    __________________________________________________________________ test_zbigarray __________________________________________________________________

        @func
        def test_zbigarray():
            root = testdb.dbopen()
            defer(lambda: dbclose(root))

            root['zarray'] = ZBigArray((16*1024*1024,), uint8)
            transaction.commit()

            dbclose(root)

            root = testdb.dbopen()
            A = root['zarray']

            assert isinstance(A, ZBigArray)
            assert A.shape  == (16*1024*1024,)
            assert A.dtype  == dtype(uint8)

            assert all(A[:] == 0)

            a = A[:]
            a[1] = 1
            a[3] = 3
            a[5] = 5
            a[-1] = 99

            b = A[:]
            assert (b[0],b[1]) == (0,1)
            assert (b[2],b[3]) == (0,3)
            assert (b[4],b[5]) == (0,5)
            assert all(b[6:-1] == 0)
            assert b[-1] == 99

            # abort - should forget all changes
            transaction.abort()
            assert all(a[:] == 0)
            assert all(b[:] == 0)
            assert all(A[:] == 0)

            # now modify again and commit
            a[33] = 33
            a[-2] = 98
            assert all(b[:33] == 0)
            assert b[33] == 33
            assert all(b[33+1:-2] == 0)
            assert b[-2] == 98
            assert b[-1] == 0

    >       transaction.commit()

    bigarray/tests/test_arrayzodb.py:95:
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    ../venv/z-dev/lib/python2.7/site-packages/transaction/_manager.py:252: in commit
        return self.manager.commit()
    ../venv/z-dev/lib/python2.7/site-packages/transaction/_manager.py:131: in commit
        return self.get().commit()
    ../venv/z-dev/lib/python2.7/site-packages/transaction/_transaction.py:311: in commit
        reraise(t, v, tb)
    ../venv/z-dev/lib/python2.7/site-packages/transaction/_transaction.py:302: in commit
        self._commitResources()
    ../venv/z-dev/lib/python2.7/site-packages/transaction/_transaction.py:447: in _commitResources
        reraise(t, v, tb)
    ../venv/z-dev/lib/python2.7/site-packages/transaction/_transaction.py:421: in _commitResources
        rm.commit(self)
    bigfile/file_zodb.py:835: in commit
        self.zfileh.dirty_writeout(WRITEOUT_STORE)
    bigfile/_file_zodb.pyx:91: in wendelin.bigfile._file_zodb._ZBigFile.storeblk
        def storeblk(self, blk, buf):   return self.zself.storeblk(blk, buf)
    bigfile/file_zodb.py:551: in storeblk
        zblk_fmt = self._zblk_fmt_heuristic(zblk, blk, buf)
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    self = <wendelin.bigfile.file_zodb.ZBigFile object at 0x7f297c99d8d0 oid 0x2 in <ZODB.Connection.Connection object at 0x7f297c99e4d0>>, zblk = None
    blk = 7L, buf = <read-only buffer ptr 0x(nil), size 0 at 0x7f297c99e770>

        def _zblk_fmt_heuristic(self, zblk, blk, buf):
            if _is_appending(zblk, buf):
                if not zblk and blk > 0:  # is new zblk?
                    # Set previous filled-up ZBlk to ZBlk0 for fast reads
                    previous_blk = blk - 1
                    previous_zblk = self.blktab.get(previous_blk)
    >               self._setzblk(previous_blk, previous_zblk, previous_zblk.loadblkdata(), "ZBlk0")
    E               AttributeError: 'NoneType' object has no attribute 'loadblkdata'

There is no guarantee that previous block is not hole.

If a user doesn't explicitly declare a ZBlk format, it can be assumed
that this user wants to have the best ratio between consumed storage space
and data access speed. Currently the best ratio between these two is
provided by the new 'h' (heuristic) format. In case of small appends this
format helps reducing storage space, and in any other case it just
behaves like ZBlk0 [1]. Therefore this default ensures a fast access speed [2],
but also avoids a massive data growth in case of many small appends [3].

[1] An exception to this is: in its current implementation a block
behaves like ZBlk1 (slow access) in case it isn't fully filled up yet.

[2] As this was stated as a reason why ZBlk1 as a default format was
reverted in nexedi/wendelin.core@0b68f178.

[3] This was perhaps the reason why ZBlk1 was set to be the default format
in nexedi/wendelin.core@9ae42085. The massive
storage space consumption can already be a problem with few array to
which regularly small data is appended to, as it can easily happen with
Wendelin development instances.

There are two formats to save data with a ZBigFile: ZBlk0 and ZBlk1.
They differ by adjusting the ratio between access-time and growing
disk-space, where ZBlk1 is better regarding to disk space, while ZBlk0
has a better access-time. Wendelin.core users may not always know yet or
care which format fits better for their data. In this case it may be
easier for users to just let the program automatically select the ZBlk
format. With this patch and the new 'h' (for heuristic) option of the
'ZBlk' argument of ZBigFile, this is now possible. The 'h' option isn't
really a new ZBlk format in itself, but it just tries to automatically
select the best ZBlk format option according to the characteristics
of the changes that the user applies to the ZBigFile.

In its current implementation, the heuristic tackles the use-case of
large arrays with many small append-only changes. In this case 'h' is
smaller in space than ZBlk0, but faster to read than ZBlk1. It does so,
by initally using ZBlk1 until a blk is filled up. Once a blk is full,
it switches to ZBlk1, as it was recommended by @kirr in
nexedi/wendelin.core!20 (comment 196084).

With this patch comes a test (bigfile/tests/test-zblk-fmt) that creates
benchmarks for different combinations and zblk formats. The test aims
to check how the 'heuristic' format performs in contrast to 'ZBlk0'
and 'ZBlk1':

---

Run append tests
---------------------------------------------
---------------------------------------------
Set change_percentage_set to 0.15
Set change_count to 500
Set arrsize to 500000
Set change_type to append

Run tests with format h:

	ZODB storage size: 318.565101 MB
	Access time: 0.747 ms / blk  (initially cold; might get warmer during benchmark)

Run tests with format ZBlk0:

	ZODB storage size: 704.347196 MB
	Access time: 0.737 ms / blk  (initially cold; might get warmer during benchmark)

Run tests with format ZBlk1:

	ZODB storage size: 163.367072 MB
	Access time: 74.628 ms / blk  (initially cold; might get warmer during benchmark)

3636242f does not talk about go-fuse, which is wcfs's direct dependency
and was actually updated by upstream:

kirr/go-fuse@9f9ad4a1

-> Update it as well.

Update all dependencies of WCFS to their recent versions:

- neo/go: Update to pick up support for NEO/go to handle multiple master nodes
- go123: Add support for Go1.21

The following dependencies were updated, but depend on higher go
versions than supported by wendelin.core

- glog: v1.1.0 needs go 1.19, but we still support go 1.18

The following dependencies were not updated by upstream at all:

- overflow
- og-rek
- errors
- testify

/reviewed-by @kirr
/reviewed-on nexedi/wendelin.core!22

Update all dependencies of WCFS to their recent versions:

- go-fuse: update to pick up https://github.com/hanwen/go-fuse/commit/265a3926
  and https://github.com/hanwen/go-fuse/commit/90b055af. The first patch
  potentially improves performance, while the second fixes support for
  neo:// with multiple masters.
- go123: add support for go1.20
- testify: some bugfixes (we use this package only during tests)

The following dependencies were not updated by upstream at all:

- glog
- overflow
- ogórek
- pkg/errors

.

/reviewed-by @levin.zimmermann
/reviewed-on nexedi/wendelin.core!16

If a NEO cluster has multiple master nodes, there is no agreed
on order in which the master node addresses appear in the URI.
In order to insure we always get the same normalized URI among different
clients of a NEO cluster with more than one master node, we explicitly
sort the master node address order with this patch.

/reviewed-by @kirr
/reviewed-on !17

In the old source code we already filtered NEO URI by dropping
credentials, but we applied this filter to any URI, not only the NEO
one. This patch adds a mechanism to apply various filter according to
the specific storage type. Starting with this new patch,
'zurl_normalize_main' also refuses to normalize an URI with an unknown
scheme.

/reviewed-by @kirr
/reviewed-on nexedi/wendelin.core!17

After moving zurl filtering to a dedicated function, we can
now test this function for correctness. It's important that different
clients which point to the same storage always result in the same
zodburi, even if their initial user-specified zodburi slightly differs
(e.g. due to different client-side parameters or different paths of encryption).

/reviewed-by @kirr
/reviewed-on !17

The WCFS mountpoint of any ZODB storage must be a unique, persistent,
repeatable hash. This means any client which uses the same storage must
always calculate the same WCFS mountpoint (independent from
client-only parameters etc.). Therefore the WCFS mountpoint calculation
must be robust for all supported ZODB storage types (at least NEO, ZEO,
filestorage).

It was recently decided [1] that in order to provide this robustness, WCFS
mountpoint calculation should filter the parsed URI in order to drop
parts, which prevents the repeatability/persistence across different
clients (e.g. parts which can differ between clients although the same
storage is accessed). In order to make this filtering implementation a
bit easier to read and the wcfs/__init__.py less dense, the first step
is to move the zurl filtering ("normalization") into lib/zodb.py
This also makes sense since this normalization can be regarded as a
general zodb tool which may be useful for other solutions which use
zodburi.

[1] neoppod!18 (comment 184671)

/reviewed-by @kirr
/reviewed-on !17

Kirill noted that nexedi/wendelin.core@fb620301 introduced a regression [1]:
'test_zstor_2zurl' sometimes passes and sometimes fails. The reason for
this is that there is no deterministic order of master nodes in
'NodeManager.getMasterList()', which is why there is no specified
order of master node addresses in a zurl [2]. We don't want to normalize
a zurl returned by 'zstor_2zurl' as we need some of the client-specific
parameters as SSL file paths, so we rather fix the test to allow any
possible order of NEO master nodes in the zurl.

[1] nexedi/wendelin.core!17 (comment 188102)
[2] https://lab.nexedi.com/nexedi/wendelin.core/blob/fb620301/lib/zodb.py#L414

/reviewed-by @kirr
/reviewed-on nexedi/wendelin.core!17

The old code raised an explicit exception when converting a NEO storage
with > 1 master nodes into a URI. Perhaps the rationale for this exception
was that there isn't any agreed on order of master nodes in a NEO URI,
which means that building a URI from such a storage could potentially
break the invariant that any client which points to the same storage
should result in the same WCFS mountpoint.
With levin.zimmermann/wendelin.core@6f5196fa we can now rely on
WCFS mountpoint calculation to always return the same mountpoint even if
the order of master node addresses differ. Therefore we can drop this
exception and allow WCFS to support NEO clusters with more than one master.

--------

kirr: support for multiple masters was simply not implemented because in
a05db040 (lib/zodb: Teach zstor_2zurl about ZEO, NEO and Demo storages)
I though that we do not yet actually need it and wanted to have
something minimal first.

I agree that in WCFS context it is ok and makes sense to normalize zurl
to have masters coming in particular order. But at zstor_2zurl level we
rely on the order of masters that app.nm.getMasterList gives us. The
normalization is separate function.

/reviewed-by @kirr
/reviewed-on !17

The function to do it was there, but I missed to add corresponding defer.
Fixes 6f0cdaff (wcfs: Provide isolation to clients).

Update all dependencies of WCFS to their recent versions:

- go123: add support for go1.18 and go1.19
- neo: update to latest draft
- go-fuse: update to pick up https://github.com/hanwen/go-fuse/commit/4a0e6eb5
- ogórek: no change, just the version we already had was released as v1.2.0
- testify: some bugfixes (we use this package only during tests)

The following dependencies were not updated by upstream at all:

- glog
- overflow
- pkg/errors

.

This patch allows using WCFS with a NEO or ZEO storage which is
reachable by a URL which contains an ipv6 host.

Without this patch the following example doesn't work:

>>> from wendelin.lib.zodb import dbopen
>>> root = dbopen("neo://cluster-name@[::1]:2051")
>>> # "abc" points to a ZBigArray
>>> root["abc"][0]

It doesn't work because the parser missed adding square brackets around
ipv6 hosts, due to which unparsing the resulting URL resulted in a wrong
interpretation where a port starts.

This patch furthermore amends 'test_zstor_2zurl' to test ZEO and NEO
storages with ipv6 hosts.

---

/reviewed-by @kirr
/reviewed-on nexedi/wendelin.core!13

This patch adds comprehensive tests for 'wendelin.lib.zodb.zstor_2zurl'.
Before this patch only one related test existed ('test_zurlstable').
This test only lightly checked correct functionality of 'zstor_2zurl'.
Therefore we added the new tests 'test_zstor_2zurl' and
'test_zurlsamedb'.

The new tests only cover existing functionality.

---

Co-authored-by: kirr

/reviewed-by @kirr
/reviewed-on nexedi/wendelin.core!13

Before this patch 'zsync(storage)' was effectless for ZEO storages, it
didn't synchronize the client with the server. This patch fixes 'zsync',
so that it also performs synchronization of ZEO clients.

Background information:
=======================

2006 the sync mode of ZEO has been removed:

  nexedi/ZEO@629b0667

and only async mode was supported from then. This means, that the "sync"
method of ZEO.ClientStorage was in fact effectless. In ZEO 5 the
"server-sync" option has been added:

  https://github.com/zopefoundation/ZEO/pull/63

Setting this option to 'True' makes the 'sync' method performing a
"server round trip, thus causing client to wait for outstanding
invalidations" [1]. In this patch we imitate the effect of this flag
for both ZEO 4 and ZEO 5.

[1] https://github.com/zopefoundation/ZEO/blob/423cb8563be3e1ee0bb4297ee980d9b74f09c710/src/ZEO/ClientStorage.py#L225-L226

---

/reviewed-by @kirr
/reviewed-on nexedi/wendelin.core!13

The 'shape' argument of 'numpy.ndarray's initialization method accepts
integer and sequences of integers. But the 'shape' property of
'numpy.ndarray' always returns tuple[int, ...], so numpy manually
casts any legal argument into tuple[int, ...].

In 'BigArray' and 'ZBigArray' this internal casting didn't exist yet.
This patch adds the casting.

Before:

  ZBigArray(shape=[1, 2, 3], dtype=float).shape == [1, 2, 3]

After:

  ZBigArray(shape=[1, 2, 3], dtype=float).shape == (1, 2, 3)

In this way BigArray and ZBigArray API behaves closer to numpy.ndaray,
which should help avoiding confusion when people are using BigArray /
ZBigArray.

-----

See issue #9 and
MR !14
for additional context.

/reviewed-by @kirr
/reviewed-on !14

Wendelin.core already supports Python3 relatively well, but demo_zbigarray.py,
that is invoked only manually, was missing compatibility bits for xrange:

    (neo) (py3.venv) (g.env) kirr@deca:~/src/neo/src/lab.nexedi.com/nexedi/wendelin.core$ ./demo/demo_zbigarray.py gen 1.fs
    I: RAM:  15.29GB
    I: WORK: 30.57GB
    gen signal t=0...4.10e+09  float64  (= 30.57GB)
    Traceback (most recent call last):
      File "/home/kirr/src/wendelin/wendelin.core/./demo/demo_zbigarray.py", line 154, in <module>
        main()
      File "/home/kirr/src/wendelin/venv/py3.venv/lib/python3.9/site-packages/decorator.py", line 232, in fun
        return caller(func, *(extras + args), **kw)
      File "/home/kirr/src/tools/go/pygolang/golang/__init__.py", line 103, in _
        return f(*argv, **kw)
      File "/home/kirr/src/wendelin/wendelin.core/./demo/demo_zbigarray.py", line 142, in main
        gen(sig)
      File "/home/kirr/src/wendelin/wendelin.core/./demo/demo_zbigarray.py", line 74, in gen
        for t0 in xrange(0, len(a), blocksize):
    NameError: name 'xrange' is not defined

-> Fix it.

Arnaud reports that wendelin.core currently cannot be installed on
Python3:

    /opt/slapgrid/3f9add9291086dee302fc478df4b3130/parts/python3/bin/python3 /tmp/tmp1fuxchsb -q develop -mN -d /opt/slapgrid/3f9add9291086dee302fc478df4b3130/develop-eggs/tmps5jr7ymsbuild
    /opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/dist.py:476: UserWarning: Normalizing '2.0.alpha2.post1' to '2.0a2.post1'
    package init file '__init__.py' not found (or not a regular file)
    Traceback (most recent call last):
     File "/tmp/tmp1fuxchsb", line 19, in <module>
       exec(compile(f.read(), '/opt/slapgrid/3f9add9291086dee302fc478df4b3130/parts/wendelin.core/setup.py', 'exec'))
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/parts/wendelin.core/setup.py", line 426, in <module>
       """.splitlines()]
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/develop-eggs/pygolang-0.1-py3.7-linux-x86_64.egg/golang/pyx/build.py", line 118, in setup
       setuptools_dso.setup(**kw)
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools_dso-1.7-py3.7.egg/setuptools_dso/__init__.py", line 37, in setup
       _setup(**kws)
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/__init__.py", line 162, in setup
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/parts/python3/lib/python3.7/distutils/core.py", line 148, in setup
       dist.run_commands()
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/parts/python3/lib/python3.7/distutils/dist.py", line 966, in run_commands
       self.run_command(cmd)
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/parts/python3/lib/python3.7/distutils/dist.py", line 985, in run_command
       cmd_obj.run()
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/command/develop.py", line 38, in run
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/command/develop.py", line 136, in install_for_development
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/parts/python3/lib/python3.7/distutils/cmd.py", line 313, in run_command
       self.distribution.run_command(command)
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/parts/python3/lib/python3.7/distutils/dist.py", line 985, in run_command
       cmd_obj.run()
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/command/egg_info.py", line 296, in run
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/command/egg_info.py", line 303, in find_sources
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/command/egg_info.py", line 537, in run
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/command/egg_info.py", line 591, in prune_file_list
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/command/egg_info.py", line 452, in prune
     File "/opt/slapgrid/3f9add9291086dee302fc478df4b3130/eggs/setuptools-44.1.1-py3.7.egg/setuptools/command/egg_info.py", line 405, in _remove_files
    TypeError: cannot use a string pattern on a bytes-like object
    While:
     Installing wendelin.core.

The problem turned out to be that git-lsfiles output, that we add into
list of source files, is bytes and it breaks when those bytes get
intermixed into strings.

-> Fix it by always returning from runcmd the str type of current python.

/reported-by @arnau

Similarly to build_ext we need ccan/config.h to be present for dso to
build. It was not the case and so pip install wendelin.core was failing:

    $ pip install wendelin.core-2.0a2.tar.gz
    Processing ./wendelin.core-2.0a2.tar.gz
      Installing build dependencies ... done
      Getting requirements to build wheel ... done
        Preparing wheel metadata ... done
    Collecting ZODB>=4
    ...
    Building wheels for collected packages: wendelin.core
      Building wheel for wendelin.core (PEP 517) ... error
      ERROR: Command errored out with exit status 1:
      ...
      running build_dso
      Building DSOs
      building 'wendelin.bigfile.libvirtmem' DSO as build/lib.linux-x86_64-2.7/wendelin/bigfile/liblibvirtmem.so
      creating build/temp.linux-x86_64-2.7
      creating build/temp.linux-x86_64-2.7/bigfile
      creating build/temp.linux-x86_64-2.7/lib
      x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -ffile-prefix-map=/build/python2.7-vgIf7a/python2.7-2.7.18=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -D_GNU_SOURCE -I/tmp/pip-build-env-lfVr7E/overlay/lib/python2.7/site-packages -I. -I./include -I./3rdparty/ccan -I./3rdparty/include -Ibuild/lib.linux-x86_64-2.7/. -c bigfile/pagefault.c -o build/temp.linux-x86_64-2.7/bigfile/pagefault.o -fno-strict-aliasing -std=gnu99 -fplan9-extensions -Wno-declaration-after-statement -Wno-error=declaration-after-statement
      In file included from ./include/wendelin/list.h:11,
                       from ./include/wendelin/bigfile/virtmem.h:50,
                       from bigfile/pagefault.c:29:
      ./3rdparty/ccan/ccan/array_size/array_size.h:4:10: fatal error: config.h: Нет такого файла или каталога
          4 | #include "config.h"
            |          ^~~~~~~~~~
      compilation terminated.
      error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
      ----------------------------------------
      ERROR: Failed building wheel for wendelin.core
    Failed to build wendelin.core
    ERROR: Could not build wheels for wendelin.core which use PEP 517 and cannot be installed directly

-> Fix it by making build_dso also first come through `make all`.

NOTE we cannot fix it in exactly the same way as for build_ext: if we split
build_dso into build_dso and ll_build_dso, `make all` will still go to infinite
recursion: build_dso -> ll_build_dso -> build_dso (not ll_build_dso, this is controlled by setuptools_dso) -> oops.

Starting from version 0.1 pygolang provides File out of the box:

pygolang@4690460b
https://pypi.org/project/pygolang/#pygolang-change-history

-> Use it and remove our custom File implementation that originally
served as POC for that pygolang functionality.

Don't use golang::* namespaces to avoid clashes with pygolang adding
something in there and getting compilation error due to conflict, when
e.g. nexedi/pygolang!17 lands.

-> use xgolang:: as top-level namespace for what was previously living
in golang:: shipped in wendelin.core.

Inside that xgolang:: namespace don't use the same package names that
might be used inside golang:: in pygolang. This avoids ambiguation and
compile error in the future on e.g. os::AfterFork - is `using namespace
golang` and `using namespace xgolang` were both activated.

-> Prefix all namespaces inside xgolang:: also with "x".

See pygolang!17

The problem is similar to a7bf0311 (wcfs: Fix crash if on invalidation
handledδZ needs to access ZODB) - I forgot to put zhead's transaction into
context.

Without the fix added test fails as:

    wcfs_test.py::test_wcfs_crash_old_data
    ---------------- live log call -----------------
    WARNING  ZODB.FileStorage:FileStorage.py:413 Ignoring index for /tmp/testdb_fs.OV0rS6/1.fs

    M: commit -> @at0 (03e5a3342bc5ab22)

    M: commit -> @at1 (03e5a3342bc88899)
    M:      f<0000000000000002>     [0]
    INFO     wcfs:__init__.py:293 starting for file:///tmp/testdb_fs.OV0rS6/1.fs ...
    I0120 17:12:10.274379  704327 wcfs.go:2393] start "/dev/shm/wcfs/556fa61a9f9675f34c6b44e1f978842c37176c59" "file:///tmp/testdb_fs.OV0rS6/1.fs"
    I0120 17:12:10.274409  704327 wcfs.go:2399] (built with go1.17.6)
    W0120 17:12:10.274560  704327 storage.go:152] zodb: FIXME: open file:///tmp/testdb_fs.OV0rS6/1.fs: raw cache is not ready for invalidations -> NoCache forced
    INFO     wcfs:__init__.py:334 started pid704327 @ /dev/shm/wcfs/556fa61a9f9675f34c6b44e1f978842c37176c59

    C: setup watch f<0000000000000002> @at1 (03e5a3342bc88899)
    #  pinok: {}

    M: commit -> @at2 (03e5a3342c895777)
    M:      f<0000000000000002>     [1]

    M: commit -> @at3 (03e5a3342ca5ef55)
    M:      f<0000000000000002>     [0]

    C: setup watch f<0000000000000002> @at2 (03e5a3342c895777)
    #  pinok: {0: @at1 (03e5a3342bc88899)}
    panic: transaction: no current transaction

    goroutine 88 [running]:
    lab.nexedi.com/kirr/neo/go/transaction.currentTxn({0x969718, 0xc0000b6240})
            /home/kirr/src/neo/src/lab.nexedi.com/kirr/neo/go/transaction/transaction.go:59 +0x77
    lab.nexedi.com/kirr/neo/go/transaction.Current(...)
            /home/kirr/src/neo/src/lab.nexedi.com/kirr/neo/go/transaction/api.go:206
    lab.nexedi.com/kirr/neo/go/zodb.(*Connection).checkTxnCtx(...)
            /home/kirr/src/neo/src/lab.nexedi.com/kirr/neo/go/zodb/connection.go:374
    lab.nexedi.com/kirr/neo/go/zodb.(*Connection).Get(0xc0000c25a0, {0x969718, 0xc0000b6240}, 0x4)
            /home/kirr/src/neo/src/lab.nexedi.com/kirr/neo/go/zodb/connection.go:331 +0x73
    lab.nexedi.com/nexedi/wendelin.core/wcfs/internal/zdata.(*ΔFtail).BlkRevAt(0xc00009dd40, {0x969718, 0xc0000b6240}, 0xc000100540, 0x30, 0x3e5a3342c895777)
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/internal/zdata/δftail.go:1140 +0x39d
    main.(*WatchLink).setupWatch(0xc0000120a0, {0x969718, 0xc0000b6240}, 0x2, 0x3e5a3342c895777)
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/wcfs.go:1754 +0xe3f
    main.(*WatchLink)._handleWatch(0x0, {0x969718, 0xc0000b6240}, {0xc0000a0122, 0x0})
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/wcfs.go:1973 +0x65
    main.(*WatchLink).handleWatch(0x0, {0x969718, 0xc0000b6240}, 0x0, {0xc0000a0122, 0x28})
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/wcfs.go:1955 +0x10c
    main.(*WatchLink)._serve.func3({0x969718, 0xc0000b6240})
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/wcfs.go:1944 +0x3c
    lab.nexedi.com/kirr/go123/xsync.(*WorkGroup).Go.func1()
            /home/kirr/src/neo/src/lab.nexedi.com/kirr/go123/xsync/xsync.go:86 +0x68
    created by lab.nexedi.com/kirr/go123/xsync.(*WorkGroup).Go
            /home/kirr/src/neo/src/lab.nexedi.com/kirr/go123/xsync/xsync.go:83 +0x92
    >>> Change history by file:

    f<0000000000000002>:
                                    0 1 2 3 4 5 6 7
                                    a b c d e f g h
            @at0 (03e5a3342bc5ab22)
            @at1 (03e5a3342bc88899) 0
            @at2 (03e5a3342c895777)   1
            @at3 (03e5a3342ca5ef55) 0

    ----------------------------------------

            # wcfs was crashing in setting up watch because of "1" and "2" from above, and
            # 3. setupWatch was calling ΔFtail.BlkRevAt without putting zhead's transaction into ctx.
            wl2 = t.openwatch()
    >       wl2.watch(zf, at2, {0:at1})

- put into if block to avoid collision with already-defined-elsewhere blkv
- show revisions in symbolic form

Noticed while working on recent change to allow ΔFtail/ΔBtail
point-queries with at=tail.

Watching with at=tail is inevitable as explained in the previous patch.

This is needed because when e.g. wcfs is just started the coverage of
ΔFtail is (head,head] i.e. empty, and if user wants to setup a watch
with at=head, it becomes watch with at=tail. Then that at is used in a
query and if point-queries with at=tail are disallowed it panics with
"at out of bounds".

This fixes crashes in test_wcfs_watch_setup (see 339f1884 "wcfs: tests:
Always start tDB with ZBigFile pre-created before WCFS startup") and in
test_wcfs_crash_old_data (see 97ce5105 "wcfs: tests: Add test do
demonstrate "at out of bounds" crash on readPinWatchers ->
ΔFtail.BlkRevAt")

For the reference zodb.ΔTail already allows point queries with at=tail:

https://lab.nexedi.com/kirr/neo/blob/1193c44e/go/zodb/δtail.go#L202-206
https://lab.nexedi.com/kirr/neo/blob/1193c44e/go/zodb/δtail.go#L225-228

The codepath that sends pin messages to watchers on FUSE READ, similarly
to what was showed in 339f1884 is also vulnerable to "at out of bounds"
panic if at=ΔFtail.tail:

    wcfs_test.py::test_wcfs_crash_old_data
    ---------------- live log call -----------------
    WARNING  ZODB.FileStorage:FileStorage.py:413 Ignoring index for /tmp/testdb_fs.nbSKXu/1.fs

    M: commit -> @at0 (03e5a31e5e5ef6bb)

    M: commit -> @at1 (03e5a31e5e63fa77)
    M:      f<0000000000000002>     [0]
    INFO     wcfs:__init__.py:293 starting for file:///tmp/testdb_fs.nbSKXu/1.fs ...
    I0120 16:50:22.136098  697106 wcfs.go:2393] start "/dev/shm/wcfs/93026d44ef96f87df2cc0e2e451c5aabee91b652" "file:///tmp/testdb_fs.nbSKXu/1.fs"
    I0120 16:50:22.136127  697106 wcfs.go:2399] (built with go1.17.6)
    W0120 16:50:22.136233  697106 storage.go:152] zodb: FIXME: open file:///tmp/testdb_fs.nbSKXu/1.fs: raw cache is not ready for invalidations -> NoCache forced
    INFO     wcfs:__init__.py:334 started pid697106 @ /dev/shm/wcfs/93026d44ef96f87df2cc0e2e451c5aabee91b652

    C: setup watch f<0000000000000002> @at1 (03e5a31e5e63fa77)
    #  pinok: {}
    panic: at out of bounds: at: @03e5a31e5e63fa77,  (tail, head] = (@03e5a31e5e63fa77, @03e5a31e5e63fa77]

    goroutine 7 [running]:
    lab.nexedi.com/nexedi/wendelin.core/wcfs/internal/zdata.panicf(...)
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/internal/zdata/misc.go:47
    lab.nexedi.com/nexedi/wendelin.core/wcfs/internal/zdata.(*ΔFtail).BlkRevAt(0xc0000a5d40, {0x969718, 0xc000076140}, 0xc0001a22a0, 0xc0001c0200, 0x3e5a31e5e63fa77)
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/internal/zdata/δftail.go:1077 +0xa45
    main.(*BigFile).readPinWatchers(0xc0001d0200, {0x969718, 0xc000076140}, 0x0, 0xffffffffffffffff)
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/wcfs.go:1559 +0x2a5
    main.(*BigFile).readBlk(0xc0001d0200, {0x969718, 0xc000076140}, 0x0, {0xc000320000, 0x200000, 0x0})
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/wcfs.go:1281 +0x4d2
    main.(*BigFile).Read.func1({0x969718, 0xc000076140})
            /home/kirr/src/neo/src/lab.nexedi.com/nexedi/wendelin.core/wcfs/wcfs.go:1223 +0x71
    lab.nexedi.com/kirr/go123/xsync.(*WorkGroup).Go.func1()
            /home/kirr/src/neo/src/lab.nexedi.com/kirr/go123/xsync/xsync.go:86 +0x68
    created by lab.nexedi.com/kirr/go123/xsync.(*WorkGroup).Go
            /home/kirr/src/neo/src/lab.nexedi.com/kirr/go123/xsync/xsync.go:83 +0x92
    >>> Change history by file:

    f<0000000000000002>:
                                    0 1 2 3 4 5 6 7
                                    a b c d e f g h
            @at0 (03e5a31e5e5ef6bb)
            @at1 (03e5a31e5e63fa77) 0

    ...

        @func
        def test_wcfs_crash_old_data():
            # start wcfs with ΔFtail/ΔBtail not covering that initial data.
            t = tDB(old_data=[{0:'a'}]); zf = t.zfile; at1 = t.head
            defer(t.close)

            f = t.open(zf)

            # ΔFtail coverage is currently (at1,at1]
            wl = t.openwatch()
            wl.watch(zf, at1, {})

            # wcfs is crashing on readPinWatcher -> ΔFtail.BlkRevAt with
            #   "at out of bounds: at: @at1,  (tail,head] = (@at1,@at1]
            # because BlkRevAt(at=tail) query was disallowed.
    >       f.assertBlk(0, 'a')          # [0] becomes tracked

Still also crashing in test_wcfs_watch_setup.

Soon this test will also exercise functionality from isolation protocol
as well and so it will stop to be basic.

Move plus rename test_wcfs_basic_invalidation_wo_dFtail_coverage ->
test_wcfs_crash_old_data.

Still crashing in test_wcfs_watch_setup.

This semantically moves initialization code from
test_wcfs_basic_invalidation_wo_dFtail_coverage (see a7bf0311 "wcfs: Fix
crash if on invalidation handledδZ needs to access ZODB") to tDB itself,
and will be useful to exercise similar scenarios in other tests.

Still crashing in test_wcfs_watch_setup.