obsolete: store metadata as a tuple of (key, value) pairs (API)

Different formats will encode metadata in different ways. So we cannot keep the
binary blob in the object anymore. We use a tuple to ensure it is immutable and
hashable.
obsolete: _rename encodemeta to _fm0encodemeta

This will be format zero specific.
obsolete: _rename decodemeta to _fm0decodemeta

This will be format zero specific.
obsolete: gather _fm0 meta encoding with other _fm0 code

--HG--
extra : rebase_source : 432df180eb7145d01f6b29023159be9d7fce237c
obsolete: use uint## in the format documention

This is shorter and kind of more readable for people who care about binary
format.
obsstore: add a flag for sha256 hashes

We add flag to inform that the marker is using sha256 hashes. As format 0 is not
able to handle sha256 hashes (32 bytes long), we plain crash if we even attempt to
encode a sha256 with it.

--HG--
extra : amend_source : 0123bee291bcc63cd04c9204d0910b8463859757
obsolete: introduce a new binary encoding for obsmarkers (version 1)

This new encoding explicitly stores the date and parents allowing a
significantly faster marker decoding. See inline documentation for details.

This format is not yet used to store format on disk. But it will be used in
bundle2 exchange if both side support it. Support for on-disk format is coming
in other changesets.

--HG--
extra : amend_source : 170e1aef82bec37c87d190f51f0145a451dae158
obsolete: add a "format.obsstore-version" config option

This option controls what version of the binary format to use when creating a new
obsstore file.

Default is still the old format. No safeguards are currently placed around the
option value, but no clueless users are in danger of harm since it is
undocumented.

--HG--
extra : rebase_source : 9889fe0f373ad2107978c59f9eab8f502c35eaf5
test-obsolete: remove subminute timezone in test

Obsmarker format "1" does not supports sub minute timezone. So we change the
test to something slightly more sensible.

--HG--
extra : rebase_source : a9e0bef480e70741c168fd6f0c1b8573d771714a
obsolete: use format version 1 as the default for obsstore

--HG--
extra : rebase_source : ee4cb641818b1fbe865f2ac7adad079e0fb8d7b2
baseset: drop custom __add__ method

This add method is enforcing non-laziness, disabling multiple optimisations.

Benchmarks do not spot any significant differences but real usecase may. This
will also be important for further improvements to addset later in this series.

--HG--
extra : rebase_source : bef5d86e0fdcf015d581710b896a3765e9e4be83
baseset: drop custom __and__ method

This add method is enforcing non-laziness, disabling multiple optimisations.

Benchmarks do not spot any significant regression but real usecase may. This
even gives some speedup in some cases:

revset #15: min(0::)
before) wall 0.001247 comb 0.000000 user 0.000000 sys 0.000000 (best of 1814)
after)  wall 0.000942 comb 0.000000 user 0.000000 sys 0.000000 (best of 2367)

This will also be important for further improvement to addset later in this series.

--HG--
extra : rebase_source : d77de8e6717a807d2dd14237e939b427435000fa
baseset: drop custom __sub__ method

This add method is enforcing non-laziness, disabling multiple optimisations.

Benchmarks do not spot any significant difference but real usecase may. This
will also be important for further improvements to addset later in this series.

--HG--
extra : rebase_source : ca8c2a874692e963a2b3afc2ebe2ba22af95c58e
test-import.t: use proper revset order

This test, written after 3.0, is relying on addset being enforced ascending if
both side are ascending. We are about to restore the ordering to 2.9 behavior
(elements are ordered in the order they are specified). We fix the test before
fixing the order.

--HG--
extra : rebase_source : b1776091172de82a584ae6d0df3082bdde425f99
addset: do lazy sorting

The previous implementation was consuming the whole revset when asked for any
sort. The addset class is now doing lazy sorting like all other smarset classes.

This has no significant impact in the benchmark as-is. But this is important
to later change.

--HG--
extra : rebase_source : 3ad323c6ee1502274c1d6fdb9487378e65e884d9
revset-_descendant: rework the whole sorting and combining logic

We use the & operator to combine with subset (since this is more likely to be
optimised than filter) and we enforce the sorting of the result. Without this
enforced sorting, we may result in a different iteration order than the set
_descendent was computed from.

This reverts a bad `test-glog.t` change from 69402eb72115.

Another side effect is that `test-mq.t` shows `qparent::` including `-1` if
`qparent is -1`. This sound like a positive change.

This has good and bad impacts on the benchmarks, here is a good ones:

revset: 0::
before) wall 0.045489 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
after)  wall 0.034330 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)

revset: roots((0::) - (0::tip))
before)  wall 0.134090 comb 0.140000 user 0.140000 sys 0.000000 (best of 63)
after) wall 0.128346 comb 0.130000 user 0.130000 sys 0.000000 (best of 69)

revset: ::p1(p1(tip))::
before) wall 0.143892 comb 0.140000 user 0.140000 sys 0.000000 (best of 55)
after)  wall 0.124502 comb 0.130000 user 0.130000 sys 0.000000 (best of 65)

revset: roots((0:tip)::)
before) wall 0.204966 comb 0.200000 user 0.200000 sys 0.000000 (best of 43)
after) wall 0.184455 comb 0.180000 user 0.180000 sys 0.000000 (best of 47)

Here is a bad one:

revset: (20000::) - (20000)
before) wall 0.009592 comb 0.010000 user 0.010000 sys 0.000000 (best of 222)
after)  wall 0.029837 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)

--HG--
extra : rebase_source : 5df2ce2743e5dadacb5911c4ab9e7a5ab4755609
extra : amend_source : d44a35429d95f7c568de286f003d825d5e6c38d7
revset: restore order of `or` operation as in Mercurial 2.9

Lazy revset broke the ordering of the `or` revset. We now stop assuming that
two ascending revset are combine into an ascending one.

Behavior in 3.0:

  3:4 or 2:5 == [2, 3, 4, 5]

Behavior in 2.9:

  3:4 or 2:5 == [3, 4, 2, 5]

We are adding a test for it.

For unclear reason, the performance `or` revset with expensive filter are
getting even worse than they used to be. This is probably caused by extra
uncached containment check or iteration.

revset #9: author(lmoscovicz) or author(mpm)
before) wall 3.487583 comb 3.490000 user 3.490000 sys 0.000000 (best of 3)
after)  wall 4.481486 comb 4.480000 user 4.470000 sys 0.010000 (best of 3)


revset #10: author(mpm) or author(lmoscovicz)
before) wall 3.164839 comb 3.170000 user 3.160000 sys 0.010000 (best of 3)
after)  wall 4.574965 comb 4.570000 user 4.570000 sys 0.000000 (best of 3)

--HG--
extra : rebase_source : a874f18661252b948753cb2521752b3467e546ed
filteredset: drop explicit order management

Now that all low-level smartset classes have proper ordering and fast iteration
management, we can just rely on the subset in filteredset.

--HG--
extra : rebase_source : c38eaa4b9668908be8c49b24280b42c2a2d1656d
baseset: empty or one-element sets are ascending and descending

The empty set is full of interesting properties. In the ordering case, the one
element set is too.

--HG--
extra : rebase_source : 46c80386c805a49a4b48284d3d881a3b4b6b7c00
revset: cache most conditions used in `filter`

Except when stated otherwise, the condition used in `smartset.filter` will be
cached. A new argument has been introduced to disable that behavior. We use it
for filters created from `and` and `sub` operations.

This gives massive performance boosts for revsets with expensive conditions.

revset: branch(stable) or branch(default)
before) wall 4.329070 comb 4.320000 user 4.310000 sys 0.010000 (best of 3)
after)  wall 2.356451 comb 2.360000 user 2.330000 sys 0.030000 (best of 4)

revset: author(mpm) or author(lmoscovicz)
before) wall 4.434719 comb 4.440000 user 4.440000 sys 0.000000 (best of 3)
after)  wall 2.321720 comb 2.320000 user 2.320000 sys 0.000000 (best of 4)

--HG--
extra : rebase_source : 41436dd6a905d2f28312ceeb0249e70a4e96751c
extra : amend_source : d354f3faae1940f92c6f2cc61448fbd0d7439e49