Fix autocomplete trigger character detection

[WunderBart]

What?

Fix trigger character detection when using multiple different triggers inline.

before	after
Screen.Recording.2023-10-12.at.17.54.50.mov	Screen.Recording.2023-10-12.at.17.51.44.mov

Closes #55118

How?

The function that finds a completer for given text content performs multiple checks before returning a matching completer. The main issue here is that there are multiple trigger characters, and if they're used side by side, the first one that matches all the criteria is returned. For the given example above, the completers are toggled between the one for @ and the one for + triggers as we type, that's why the popup sometimes disappears, as the matching string is different on each keystroke.
We should not be relying on the order of the triggers array, so to address this, I've added a step where the completer is picked by the closest trigger character to the end of the current text content. After that, all the checks that were there before are performed as well to ensure there are no regressions.

Testing Instructions

Follow the steps to reproduce what has been recorded on the before and after videos above.

0. checkout trunk and follow the steps described in Mentions autocomplete is unstable #55118 to see the regression.
1. checkout this branch,
2. create a new post,
3. start typing a mention, trigger with @,
4. hit enter to apply the found mention,
5. hit space and start typing another mention; this time start with +,
6. type at least 4 characters of the searched mention,
7. ensure the results popup is visible on each keystroke.

All the E2E tests should pass.

[github-actions]

Flaky tests detected in df24fddcdd4300df3669a29204c3b9e397250054.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6498655061
📝 Reported issues:

• [Flaky Test] should partially select with shift + click (@webkit) #53524 in /test/e2e/specs/editor/various/multi-block-selection.spec.js

[chad1008]

@WunderBart, how are you accessing the + completer for these testing steps? I've been using the localhost:8889 instance from wp-env and activating the Gutenberg Test Autocompleter plugin that creates that completer for the e2e tests that helped reveal the instability. From your testing instructions it sounds like you might be doing it differently?

[WunderBart]

@WunderBart, how are you accessing the + completer for these testing steps? I've been using the localhost:8889 instance from wp-env and activating the Gutenberg Test Autocompleter plugin that creates that completer for the e2e tests that helped reveal the instability. From your testing instructions it sounds like you might be doing it differently?

Ah, good question! Here's what I do to use the env from that autocomplete test:

1. Add await page.pause() right after the test env setup is done, which in this case should be here.

2. Run that test in headed mode so that it's actually paused:

   npm run test:e2e:playwright -- -g "should insert elements from multiple completers" --headed
   

3. Wait until the browser opens and the execution is paused.

4. Go to http://localhost:8889/wp-admin/post-new.php in your browser or Playwright's instance (should be already there when paused).

5. You should now be able to use the autocomplete data created for that test.

6. When done testing manually, unpause or close the Playwright test runner.

[chad1008]

Thanks for those steps @WunderBart, I wanted to make sure we were testing the same things! I was actually noticing another odd behavior, but it doesn't look related to this PR at all:

When I first load the editor and start enter a user mention, the autocomplete options appear to re-render on each character, but only for the first time I try it. All subsequent uses of Autocomplete render once and just filter out options as I go. This looks like it happens on trunk and with either of the testing methods I used though, so again, I think it's completely unrelated.

Testing this PR using both your steps and my own approach to activating the secondary + completer, this feels solid to me. The second completer consistently renders the options without dropping them on every other character like trunk currently does, and if I log out the currently selected completer as I go everything looks good 👍