"edit.getFixes"/"edit.getAssists" can be slow and called a lot by IntelliJ/Android Studio

[DanTup]

There are multiple performance issues coming up in #55281 which makes it a bit hard to track them (and their solutions), so I'm adding sub-issues for some individual issues that have been identified.

One issue is that IntelliJ/Android Studio can call edit.getFixes and edit.getAssists quite frequently, and sometimes these requests can be slow and back the server up.

@jensjoha added some notes about this at #55281 (comment) and has added some debouncing at https://dart-review.googlesource.com/c/sdk/+/413682, however I think this request is also taking too long and it might be that the client should also have some delay/debouncing to avoid so many requests while typing?

An example of how this appears in the diagnostic repo can be found attached to #55281 (comment), which contains slow requests like below (notice they appear to be taking around 500ms each and being sent repeatedly at around the same interval):

[bwilkerson]

@johnniwinther Not sure why this is area-dart-model; it looks like most or all of the work for this issue is in the server.

One of the other things we can do in this space is to improve the performance of edit.getAssists. I was talking to @pq a couple of days ago and suggested that we might be able to use an approach similar to the one we use for fixes to reduce the number of CorrectionProducers we are required to run for a single request. (Basically, use a table keyed by AST node class, similar to the way fixes are keyed by diagnostic code.)

A similar approach could be used for refactorings and snippets if either of those ever appear to be taking too long to compute.

[johnniwinther]

Ok. I'll move it to area-devexp. I added the model-performance label to group this issue with other performance related work currently ongoing.