10 seconds is apparently not enough on a busy machine: with it I'm seeing
several failures where glog is stuck in fsync flushing its buffers, for
example:

https://nexedijs.erp5.net/#/test_result_module/20210817-E9535884/25
https://nexedijs.erp5.net/#/test_result_module/20210817-130D3B7A2/23
https://nexedijs.erp5.net/#/test_result_module/20210817-130D3B7A2/21
...

let's try to double the timeout.

X wcfs/xbtree: Fix update not to add duplicate extra point if rebuild  - called by Update - already added it

It was failing e.g. as

=== RUN   TestΔBTail/rebuild/T4/T1,3-T/T-T-T-T/B0:b-B1:c,2:j-T-B4:d/B3:h→T/T2,3/T-T-T/B1:d-B2:c-B3:i/_T{3};R/_→T2/B1:g-B2:c,3:i
    δbtail_test.go:917: after Update(@at1→@at2): vδT:
        have:
        	@at1: map[0:{b ø} 1:{c d} 2:{j c} 3:{h i} 4:{d ø}]
        	@at2: map[1:{d g}]
        vδb/root:
        	@at1
        	@at2
        	@at2	<-- HERE

https://nexedijs.erp5.net/#/test_result_module/20210816-95C3A93E/5

xbtree tests, in normal mode, run ~ 130s on my laptop. On a testnode
however they run ~500s and sometimes more than 10 minutes, probably
depending on surrounding load.

-> increase default `go test` timeout to avoid sporadic "test timed out"
failures.

This is what we are interested in the first place.
For full details -vv will show *.py logs verbosely.

This makes sure those programs are always built afresh instead being
stuck at outdated build. This is needed because corresponding test .c
file includes many other .c files and we don't implement dependency
tracking.