Cancel queued findWordsWithSubsequence jobs when mutating a buffer

[maxbrunsfeld]

Fixes atom/atom#16153
Fixes atom/atom#16159
Fixes atom/language-shellscript#88

Background

After enabling the new Subsequence autocomplete provider by default in Atom, we observed a bad slow-down when holding down an alphanumeric key. This was happening because we would were calling findWordsWithSubsequence many times in rapid succession, interspersed with buffer changes. This was resulting in a large number of text buffer layers being created.

Solution

We have made three changes to fix this problem:

1. When mutating a TextBuffer, we now cancel any findWordsWithSubsequence jobs that were initiated before the mutation and are still queued. Those calls will then resolve with null. This is ok because the result of those calls is no longer needed - a character has been typed since they were performed.

2. We have optimized the internal TextBuffer::clip_position method so that in its cost now scales linearly with number of buffer layers. Previously it accidentally scaled exponentially with the number of layers because each layer would call clip_position twice on its underlying layer.

3. We have placed a hard limit on the number of subsequence match variants that we consider when scoring a given match. This stops the findWordsWithSubsequence background thread from using an amount of time and memory that scales exponentially with the length of the query (the word fragment preceding the cursor in Atom).
   I have some ideas for algorithmic improvements to the scoring algorithm that will remove the exponential behavior entirely, but I think we can merge this PR as-is in order to fix the pressing problem in Atom.

[Arcanemagus]

Does this also fix atom/language-shellscript#88? The Atom issues were marked as a duplicate of it, but the behavior is different.

[nathansobo]

I know this is the only case where we have outstanding workers, but might it make sense to give this set and the cancellation method a specific name... to cancel outstanding subsequence searches?

[maxbrunsfeld]

I think that in the future, it needs to include other types of workers as well. For example, you can trigger the same problem by calling findAll(regex) many times rapidly, interspersed with buffer changes. We haven't made those calls cancellable yet. I'm not sure if we should do that as part of this PR, since currently there's nothing in Atom that would call that API on every keystroke. Maybe we should just go ahead and do it though.

[nathansobo]

Yeah, that makes sense. This set is for anything that should be cancelled on the next edit.

[maxbrunsfeld]

Does this also fix atom/language-shellscript#88?

Yes, I believe so! Added to the description. Thanks @Arcanemagus.