Enhance step completion with usage-based ordering

[maciekpazola]

Introduce new functionality in DeveroomCompletionSource.cs and StepDefinitionUsageFinder.cs to enhance step completion in the Reqnroll Visual Studio extension.

In DeveroomCompletionSource.cs:

• Update GetStepCompletions to retrieve feature files and configuration, use StepDefinitionUsageFinder to order steps by usage, and return top 5 steps with a star and usage count.
• Minor formatting changes in AddCompletions method calls.

In StepDefinitionUsageFinder.cs:

• Import Reqnroll.VisualStudio.Editor.Completions namespace.
• Add FindUsageCounts method to aggregate step definition usage.
• Introduce FindUsageCountsFromContent to parse feature files and count step occurrences.
• Add helper methods and classes to support new functionality.

🤔 What's changed?

-Steps completition are now sorten by usage in projects
-Step description contains "Usage {usage count in a project}"

-For top 5 steps there is '★' added to visually see most common steps

⚡️ What's your motivation?

It's implementation for this Idea:
https://github.com/orgs/reqnroll/discussions/331#discussioncomment-11680454

🏷️ What kind of change is this?

• ⚡ New feature (non-breaking change which adds new behaviour)

♻️ Anything particular you want feedback on?

📋 Checklist:

• I've changed the behaviour of the code
  • I have added/updated tests to cover my changes.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• Users should know about my change
  • I have added an entry to the "[vNext]" section of the CHANGELOG, linking to this pull request & included my GitHub handle to the release contributors list.

---

This text was originally taken from the template of the Cucumber project, then edited by hand. You can modify the template here.

[gasparnagy]

I think the idea of this feature is good and the usage-based ordering and usage count hints are useful.

However we would need to rethink how this is provided because the performance of the current implementation is not sufficient.

I have made some tests with 3 projects:

1. Calculator,
2. Smaller project that I currently work on (89 feature files),
3. bigger project with 500 feature files. (I have clients with more than 1500 feature files!)

Before the PR, populating the completions took 0-5 ms, but with the PR the average times are 12, 262 and 1503 ms. While the 12ms with the calculator sample is not a problem, with the smaller project, de delay was already annoying. For the bigger project it felt it is frozen.

The concept of the VS extension contained two important goals:

1. Make the editing experience of feature files smooth (no UI block for more than 20-40 ms)
2. Keep the extension conveniently usable even for 1000+ feature files.

This is the reason why we don't parse through all the feature feature files for a particular command. Find usages uses an async behavior and populates the list without blocking the UI.

Still, knowing about the step definition usages in files would be useful. We could use them for completions (like you do), but also for better suggestions on step parameters as well and maybe for some other things too.

But I think we can only achieve this by calculating the usages in the background. So it should be some background service that recalculates itself time-to-time (when?). But this is not that easy.

Do you have time to play with it and try to make some async usage calculation?

To make the things simpler, we could trigger the calculation on the first use (in the background), so for the first use the ordering and the starts would not be available yet, but for the subsequent calculations they could already be displayed. It is also not a problem if we never re-calculate (at least in the first version), because it is unlikely that newly added step definitions will go to top 5.

[maciekpazola]

@gasparnagy sure no problem, I can play around with it and see if I can manage to create such service

[304NotModified]

Im not sure if this pr is still in progress.

Besides the background task, there are some changes that could improve the performance:

• Creating thousands (empty) dictionaries is expensive. We should prevent that if possible.
• Creating collections, like dictionaries, with the correct initial capacity will safe a lot of cpu/memory usage.
• Taking the top 5 could be done in O(n), sorting the whole list is not needed and expensive - probably O(n log(n)), see https://www.bigocheatsheet.com/

[304NotModified]

Closing this due to inactivity. Feel free to reopen in the future!