This commit fixes the tests (except those from voting.ml) which failed when the value
of tokens_per_roll (from src/proto_alpha/lib_protocol/src/constants_repr.ml) changes.
Notably, 2 functions were deleted with get next baker by priority from double_baking.
They were used only in one test and they were creating pairs of baker and index,
but this index did not necessarily correspond to the baker's priority.
There is no notion of unauthenticated connection, since the function
`authenticate` is immediately called on a
`P2p_io_scheduler.connection` and returns an authenticated connection,
or nothing. So, we only deal with authenticated connections. The
identifier of a connection is the same one as the one of the
`P2p_io_scheduler.connection` underneath.
Use it to output a minimal `./tezos-node --version`
Works both when you compile inside a git repository or from an
archive generated by `git archive` (which is what gitlab does when
you click on "Download zip/tar.gz/tar.bz2" in the web interface)
First this patch makes build-deps non interactive as it should be.
More importantly, it changes the optimization problem sent to the
opam solver (and that may be a big deal).
By default the criteria is `-removed,-changed,-notuptodate`.
-changed is problematic because it means that if a dependency
has been updated in tezos-opam-repository but all tezos packages
are fine with the one currently installed, it is not changed (but
as we observe now there might still be in fact packages with
undeclared incompatible with this old version)!
-remove is also problematic because what we would like to say is
"minimize the number of removed 'root' packages" we don't care to
remove packages automatically installed and not necessary anymore
(especially when they don't compile anymore with updated version of
their deps...)
So... I reversed order in the criteria. I'm sure this is what I want
when the opam switch contains only tezos-opam-repository but
unexpected upgrades occur for devs that have done a
`opam repo add default --rank=-1`...
for a proposal to be valid it must either a protocol that was already
proposed by somebody else or a protocol known by the node, because the
user is the first proposer and just injected it with
tezos-admin-client
