repo-config: clarify why we seems to parse the repository "twice" That is not the first time I am confused about this code, lets add a comment to save time in the future.

config: type `rcutil` It helps to understand what is going on here and catch future errors.

config: extra the code showing config in its own module too This conclude our extract of the main semantic in a dedicated module.

config: move "component display" in the new module That part seems dubious, but at least it is now isolated. I added inline comment about how "suboptimal" it is.

config: move edition code in its own module We start to move code related to the command outside of the main commands modules for clarity. This also highlight some flaw in this code and the new flag are missing some error handling. However we will deal with them later. This move removes the needs for a few module import in the `commands.py` which I see as a good sign.

config: move `rcutil` module under a new `mercurial.configuration` module This new module aims at gathering configuration related code, rcutil definitely deserves to live there.

rust-pyo3: plugging in the dagop module We refrain from removing its counterpart in `hg-cpython`, so that comparisons can easily be made.

rust-pyo3: simplified API to get core Index references Given the amount of conversion and arcane internal detail, it is easier for the caller and makes a better separation of concerns to just introduce a new unsafe helper. It is actually possible that it would be safe, and we can decide about that later. Actually the reason given in the `cpython` crate for unsafety of the `try_borrow()` method is the following: ``` // try_borrow() and try_borrow_mut() are unsafe because self.data may // have a function returning the inner &'static reference. // If T is &'static U, its lifetime can be easily coerced to &'a U, but // how could we do that for Whatever<'static> in general? ``` Given that we coerce the Index reference to the GIL lifetime and that it is unlikely that the inner data would contain a function returning the a `'static` reference, it is possible that it is actually even safe.

rust-pyo3: dagop submodule implementation This is the first demonstration that the passing of objects through the Python interpreter from `rustext` to `pyo3_rustext` actually works. In the Python tests, we conflate the presence of the `pyo3_rustext` package with that of `rustext`, as we do not plan to support building one and not the other (we hope to convert fully to PyO3 soon). The skipping is actually done by the base test class. The implementation of `rank` is as trivial as it was in `hg-cpython`, yet it required to be able to convert exceptions from `vcsgraph`.

rust-pyo3: conversions to GraphError Python exception The nice thing is that with PyO3, exceptions can be instantiated without holding the GIL. Hence the only thing that prevents us to implement `Into<PyErr>` for `hg::GraphError` is that neither is defined by the current crate. We could use a wrapping "newtype", but the compiler is not so clever yet that it could chain automatically to two needed `into()`, so we'll end up with some type conversion anyway, involving something like `GraphErrorWrapper`. At this point, explicitly named methods are just simpler.

rust-pyo3: retrieving the InnerRevlog of hg-cpython This allows PyO3-based code to use the InnerRevlog, access its shared data (core InnerRevlog), which will then allow, e.g., to retrieve references on the core Index. On the `hg-cpython` (`rusthg` crate, `rustext` Python extension module), we had to also build as a Rust library, and open up some accesses (see notably the public accessor for `inner`, the core `InnerRevlog`). Retrieving the Rust struct underlying a Python object defined by another extension module written in Rust is tricky because the Python type objects are duplicated in the extension modules, leading to failure of the normal type checking. See the doc-comment of `convert_cpython::extract_inner_revlog` for a complete explanation. To solve this, we import the Python type object of `rustext` (defined by `hg-cpython`) and perform a manual check. Checking the Python type is necessary, as PyO3 documentation clearly state that downcasting an object that has not the proper type is Undefined Behaviour. At this point, we do not have conversion facilities for exceptions (`PyErr` on both sides), hence the remaining unwraps).

rust: made the crate of hg-cpython importable The crate name is actually `rusthg`. This has the side effect of running the doctest of the `py_shared_iterator` macro which was really inconsistent, and after basic fixes, exposed that the macro itself was poorly scoped.

rust-pyo3: conversion helpers for Revision objects Although the PyO3 API is indeed nicer and has derive macros, we still need the collection helpers. The `Result` issue is not very relevant any more, however the checking of incoming revisions for Python definitely is.

rust-pyo3: defining GraphError This pretty much parallels the way in works with `cpython`. A warning, though: this new `pyo3_rustext.GraphError` is not the same as `rustext.GraphError`, yet both subclass `ValueError`.

rust-pyo3: facility for submodule registration, using it for dagop It turns out that PyO3 has the exact same problem that we encountered long ago with rust-cpython. The only difference is that the value of `__name__` is not within the `mercurial` package at this point of registration. We reimplement the solution (equivalent to the suggestions in PyO3 issue tracker anyway), this time in a generic module to limit the amount of boilerplate in subsequent applications.

rust-pyo3: change the name of the Python module to pyo3_rustext Two reasons for doing so - `pyo3-rustext` is not a valid Python identifier, hence the module could only be imported with `__import__("mercurial.pyo3-rustext")` and then retrieved by getattr. Normal usage is throught `mercurial.policy`. Hovever manual testing for development and perhaps unit tests can benefit a more natural way of doing. - The module's `__name__` attribute was already `pyo3_rustext`. This can lead to some discrepancies, in particular when we introduce submodules.

testing: stop skipping all Python tests of Rust revlog This base class was not adapted for the introduction of `InnerRevlog`, which also stopped exposing an `Index` class from `rustext`. As a consequence, `test-rust-ancestor.py` was always skipped (and would have been slightly broken). We remove the skipping conditions from `rustancestorstest`, as they now contradict or repeat those of the base class. Also, `LazyAncestors` objects apparently hold only one reference to the inner revlog (they had previously two references on the Rust index). What matters most of course is the return to `start_count` in these tests, i.e., that there is no memory leak nor double frees. In the Python test, we conflate the presence of the `pyo3_rustext` package with that of `rustext`, as we do not plan to support building one and not the other (we hope to convert fully to PyO3 soon). The skipping is actually done by the base test class.

rust-cpython: fix discrepancy in internal FFI lib version The dependency to `sys-python3` stayed at version 0.7.1 when `cpython` got bumped to 0.7.2 for Python 3.12 support. In pratice, this does not change much because Cargo rules imply that this means ">= 0.7.1, <0.8.0". Still it did not feel right, either `cpython` enforces a stricter version and this specification is not needed at all, or it meant that it was still possible to install the older version of `sys-python3`.

hg-pyo3: bump pyo3 to 0.23 Comes with significant API changes.

rust: add PyO3 based Rust extension module Rebased by gracinet on top of cleanups for the Mercurial 7.0 development cycle.