rust-pyo3: new helper for incoming iterables of revisions The pattern to borrow the core `Index` from the index proxy, and using it in `rev_pyiter_collect` is frequent enough in what remains to be converted from `hg-cpython` that it is worth having this direct helper (and it will neatly enclose the unsafety).

rust-pyo3: implementation of LazyAncestors There is a difference in the implementaion of `__contains__` between PyO3 and rust-cpython: if the specified signature in Rust code is for a precise type (e.g., `PyRevision`) rust-cpython would automatically convert the potential resulting `TypeError` into `Ok(false)`, whereas PyO3 let it bubble up. Hence we treat the case manually and add it to the common test. In Mercurial Python code, `None in` for a `LazyAncestors` object can really happens, namely in this lambda from `discover._postprocessobsolete`: ``` ispushed = lambda n: torev(n) in futurecommon ``` This lambda can get called with `n` such that `torev(n)` is `False` (seen in `test-bookmarks-push-pull.t`).

rust: test AncestorsIterator without duplication Up to now, it was acceptable to duplicate the test in `test-rust-ancestor.py` that was relevant to `dagop`. Now that we have more PyO3 implementations, it is better, and actually more convincing, to express the tests in a common base class (has technically to be a mixin to avoid running the tests from the base class itself).

rust-pyo3: exposition of AncestorsIterator Compared to the early experiments, we have one less `RwLock` in the wrapping. Still that is somewhat redundant with `UnsafePyLeaked` being itself some kind of lock. In the original rust-cpython code, we were borrowing the `RefCell` with a method that can panic. Instead we are now converting the `PoisonError` that unlocking a `RwLock` can produce. Since all methods acquiring the `RwLock` are themselves protected by the GIL and do not release it before returning, nor do they leak RwLock guards, there is no risk of contention on these locks themselves.

rust-pyo3: generic borrows of UnsafePyLeaked with error treatment Maybe we will find later a more pleasant way to express safety. Meanwhile, these helpers are useful because of the proper error propagation, and will help to avoid too much cruft in the caller code.

rust-pyo3: error propagation for UnsafePyLeaked wrapping a result This `py_leaked_or_map_err` is the PyO3 version of the function of the same name in `hg-cpython/src/ancestors.rs`.

rust-pyo3: getting rust-cpython GIL handle from various PyO3 objects Depending on the caller context, we might have a `Python<'py>` around or any of the smart pointers that bear the GIL lifetime. Of course, all of these can give back a `Python<'py>` but it is worthwile to reduce the needed boilerplate. The trait just expresses that a lifetime is assumed to be outlived by the PyO3 GIL lifetime. It is marked as unsafe because that is just trusting the implementor. A first version of this was made of a safe trait with a `get_py()` method and the corresponding trivial implementations. We found it finally to be even more artificial, as it boils down to coding 4 functions doing and returning no real data, that we hope the compiler will optimize away.

rust-pyo3: intermediate ProxyIndex extraction Retrieving the `UnsafePyLeaked` without borrowing it will be necessary for the upcoming classes that need to store an inner object derived from it.

rhg: set group-writable checkisexec file permissions in Python This actually achieves what the parent commit tried to do, but on the Python side. Unfortunately, `mkstemp` doesn't seem to let us specify the initial file permissions so we have to apply umask by hand when chmodding.

rhg: set the expected temp file permissions (0o666 minus umask) This continues the theme of a48c688d3e80, and fixes the bug #6375, which was causing some problems for us, where a non-group-readable file can't be copied, which breaks some tools that copy the repo. This affects both the `checkexec` file and the temporary file we use for filesystem time measurement, since either of these files remaining on disk can cause this problem, and the 0666 permissions are just the better default here.