CompletionService refactoring and small tweaks to import completion

[genlu]

This is extracted from #59045.

Other than refactoring, there's also a few notable changes to the behavior of import completion (which lays the foundation for the additional changes in #59045):

1. Returns partial result if cache is not fully populated (this is for unimported types, provider for unimported extension methods already does this)
2. Selecting expander no longer force cache population and returning of complete result. Partial result will be returned if cache is not fully populated.
3. Timebox (500ms) for unimported extension method provider is removed. This is not the intended final behavior, additonal change in Don't block completion for items from unimported namespaces #59045 would ensure completion do not block on import completion. This also fixed CancellationTokenSource disposed in AbstractExtensionMethodImportCompletionProvider.cs #58932
4. Always show expander in the filter list. If we are not in the proper context or no expanded items would be available, then selecting it would be a no-op. This simplifies the implementation w/o (IMO) causing any UX issue.

[CyrusNajmabadi]

move to separate file. my pref on formatting would be:

        private readonly record struct VSCompletionItemData(
            string DisplayText,
            ImageElement Icon,
            ImmutableArray<AsyncCompletionData.CompletionFilter> Filters,
            int FilterSetData,
            ImmutableArray<ImageElement> AttributeIcons,
            string InsertionText);

Taht way all the properties are very clear.

[CyrusNajmabadi]

please move to separate file.

[genlu]

That feels unnecessary to me, given this is a private, one-line auxiliary type. Is this required by our convention?

[CyrusNajmabadi]

why not use SleectAsArray? i'm not sure how this new code is better.

[genlu]

items is a pooled list, not an ImmutableArray, I think the overload of SelectAsArray for it doesn't create the instance of ArrayBuilder with a capacity. Give the potentially large size of this list, this would avoid call to EnsureCapacity thus reduce allocation.

[genlu]

note that eventually we'd want to avoid potentially LOH allocation here, by asking for a new API from editor so we don't need to realize any ImmutableArray, and use pooled object instead.

[CyrusNajmabadi]

what experiment do we still have here?

[genlu]

Import completion is still disabled by default, we use an experiment to turn it on for all internal users.

[CyrusNajmabadi]

have you considered just using a AsyncBatchignWorkQueue instead?

[genlu]

Will look into it, and change in a follow up PR if it's feasible.

[CyrusNajmabadi]

i'm overall ok with this. my general feedback is similar to before. the refactorings are helping with complexity. but as you go inot methods have a strong eye toward doc'ing what is going on and making it so the methods are clearer in purpose and logic.

Since you're doing several PRs this can be slowly done as you do all the work. but ideally the end result is that all the individual pieces feel clearer and far less complex when people are workign with them.

thanks!

[CyrusNajmabadi]

approved, with requests for some changes.