Upon investigation into the code being removed, this mostly triggered whenever an empty transform appeared in the input - during a context reset, at initialization, or when a deadkey is typed. (Deadkeys aren't sent to the pred-text engine.) This is generally not a common case within the engine, and there exists other filtering that helps prevent duplicating search results.
Suppose a token that begins tagged with an empty transform. When the search performs an 'insertion' to better lookup words down a lexical path, the 'insertion' is identical whether before or after an empty transform. Similarly, insertions after a deletion appear no different than substitutions (or the same insertion before the deletion, then the deletion itself).
The code likely didn't gain us much, as it likely carried some performance overhead - it built a large object that required memory and lookup time that involved constructing and processing strings for hashing.
Build-bot: skip build:web
Test-bot: skip
When we start supporting more than one "space" for correction-searches, we may need to know which "space" (tokenization) a suggestion arose from. This way, we have a path forward for applying tokenization-dependent behaviors that may be required.
Build-bot: skip build:web
Test-bot: skip
This new interface is being added in preparation for efficient multi-tokenization correction-search. SearchQuotientSpur has been modified to implement it, and a new type (SearchQuotientNodeImpl) will be added in the near future as an additional implementing type.
Build-bot: skip build:web
Test-bot: skip
This changes SearchQuotientSpur to construct new instances whenever the path is extended, treating SearchQuotientSpur as an immutable portion of the search graph that may be extended by new input, creating new instances of SearchQuotientSpur.
This, in turn, removes the need to clone SearchQuotientSpur instances when new input is received for an incoming token; the original instance's represention will remain unchanged and may also be reused by a new instance extending the graph for the newly-received input.
Relates-to: #14445
Build-bot: skip build:web
Test-bot: skip
SearchSpace itself will become an _interface_ implemented by what is now SearchPath, and another type also implementing it will be introduced in an upcoming PR.
We now track maximum individual probability for any one input in the full, source fat-finger distribution. For some tokenizations, the corresponding input will not be considered, but that should not affect thresholding behaviors.
Build-bot: skip build:web
Test-bot: skip
This change simplifies the mechanics of each SearchSpace by dropping the complexity of managing an intermediate tier. This does get rid of a mild boost that assistss the correction-search process in prioritizing nearly-completed correction paths, but we should rework that heuristic anyway - especially in light of upcoming changes and potential complications once we start supporting correction from alternate tokenizations.
Build-bot: skip build:web
Test-bot: skip
