relnotes: advertize the possibility to use rust I think the rust work may have been mentioned in the release notes, but if so only in passing, and not as an invitation to try it out. I think the next version is a decent time to do this, because the rust doesn't come with performance regressions AFAIK, speeds up status noticeably when it applies, which is the case for most invocations of status, and doesn't have the undesirable restriction of regex around empty patterns anymore. I am cheating a bit, because I'm giving numbers for `hg status` in mozilla-central, but they have one hgignore pattern that uses lookaround, ".vscode/(?!extensions\.json|tasks\.json", which I took out as it would cause a fallback to python when unknown files are requested. But it seems that they could express their hgignore differently if they were so inclined. Not sure if there are limitation other than linux-only that I am not thinking of but would be worth mentioning upfront, to avoid disappointing users? Differential Revision: https://phab.mercurial-scm.org/D8604

== New Features ==


== New Experimental Features ==

 * The core of some hg operations have been (and are being)
   implemented in rust, for speed. `hg status` on a repository with
   300k tracked files goes from 1.8s to 0.6s for instance.
   This has currently been tested only on linux, and does not build on
   windows. See rust/README.rst in the mercurial repository for
   instructions to opt into this.

== Backwards Compatibility Changes ==

* Mercurial now requires at least Python 2.7.9 or a Python version that
  backported modern SSL/TLS features (as defined in PEP 466), and that Python
  was compiled against a OpenSSL version supporting TLS 1.1 or TLS 1.2
  (likely this requires the OpenSSL version to be at least 1.0.1).


== Internal API Changes ==

 * logcmdutil.diffordiffstat() now takes contexts instead of nodes.

 * The `mergestate` class along with some related methods and constants have
   moved from `mercurial.merge` to a new `mercurial.mergestate` module.