Cache command picks for the duration of the quick pick

[Tyriar]

Fixes #200548

The PR seems to work, the main things that need clarity are:

• Whether this is the right place to do the caching, I'm sure there's a more elegant way to do this.
• Does it invalidate the cache correctly, are there edge cases I'm missing?
• Should we do this more generally? I'm not sure how dynamic providers can be.

It essentially removes this getCommandPicks entirely when filtering, until the provider changes:

Below are some numbers in milliseconds of the duration of _getPicks before and after when filtering 1+ letters.

Before

• 12.72
• 10.05
• 17.49
• 10.90
• 11.11
• avg 12.45

After:

• 3.39
• 2.11
• 3.88
• 4.46
• 4.21
• avg 3.61 (-8.84, -72%)

Since the change reduces the work by about 9ms, this is expected to more often than not display the results in 1 less frame on a 60Hz display and almost always in >= 1 less frame on a 144Hz display.

[TylerLeonhardt]

One of the things I'm currently worried about with this change is that I wanna know what happens when you start the Command Palette right away at start up... I worry that that initial list doesn't contain all commands because some components are delayed in their initialization. We do wait a bit but it might not be enough for low end machines.

I'd be fine accepting this and see what insiders has to say though. cc @bpasero for any historical insight.

[bpasero]

I think this is a slippery slope: commands are not that static:

• they can change based on the active editor which you can change while picker is opened
• pickers can be cancelled when you jump to another picker which then could mean we accidentally cache an empty array because of that cancellation

I am also not a big fan of the explicit new method to clear cache, ideally the picker implementation could do this internally, for example by wiring this into the disposable or when a command is accepted.

[Tyriar]

@TylerLeonhardt could we do a quick command count check and reload to avoid problems there? We could move the caching into getCommandPicks itself with that? We could also cache getCodeEditorCommandPicks and getGlobalCommandPicks independently (post mapping into picks to save more time).

@bpasero sure it would be better to not need to do this, but 9ms is a significant price to pay on every keystroke. I think the above suggestion mostly addresses your concern.