As part of {T254074} we want to implement manual revert detection in addition to the current undo- and rollback-based triggers. A manual revert is made when the editor reverts the page to an exact previous state, not using the built-in undo or rollback functionality. See T252366 for a discussion on this.
This should be implemented using exact SHA-1 matching of revisions in the database vs the current revision. As that field lacks an index over it, we'll need to search only within a certain radius of revisions, which can be configurable. [[https://md.ekstrandom.net/pubs/isw09-wiki-viz.pdf | This paper]] suggests using 15 revisions as the default radius (that is also what Product Analytics team uses by default for their [[https://pythonhosted.org/mwreverts/detection.html | mwreverts]] library). I think this can be done with a single relatively inexpensive DB query utilizing the LIMIT clause. I hope the query optimizer is smart enough to make it a scan of 15 rows, instead of the entire table, I'll have to double-check this, though. I think we'll need to read this data from master, to avoid issues with replication lag, though I'm not 100% sure on this.
The DB code should probably be added to the RevisionStore class, while the remaining logic can live in the EditResultBuilder. The code will be triggered by EditResultBuilder::buildEditResult().
Also: should we mark manual reverts with a software-defined edit tag, like `mw-undo` and `mw-rollback`? This would certainly be consistent with the other forms of reverts, and the fact that these manual reverts will mark reverted edits just like undo and rollback will.