configure autocomplete provider based on cody LLM settings in site config

[taras-yemets]

Part of #931
Test in pair with sourcegraph/sourcegraph#56568

Defines the autocomplete provider config based on the completions provider and model names from the site config.
The suggested configuration hierarchy:

1. If cody.autocomplete.advanced.provider field in VSCode settings is set to a supported provider name, and all the additional conditions like model, access token, etc. are met the corresponding provider config is returned. Otherwise, return null (completions provider is not created).
2. If the provider name and model can be defined based on the evaluated feature flags, return the corresponding provider.
3. If the completions provider name is defined in the connected Sourcegraph instance site config, we return the corresponding provider config. If the provider name/model can't be parsed or this provider is not supported null is returned (completions provider is not created).
4. Anthropic config provider is used by default.

TODO:

• Add createProviderConfig tests

Test plan

• CI passes

[taras-yemets]

I wonder if we should fall back to the completions provider from site config if provider/model/token is misconfigured in VSCode settings. The current approach for this case is not to create any completions provider. It may be more user-friendly. WDYT, @chwarwick?

[philipp-spiess]

if provider/model/token is misconfigured in VSCode settings. The current approach for this case is not to create any completions provider.

yeah this was done on purpose so if you really manually set something, we can show you what's wrong and not "silently ignore it and leave you with no debug info"

[chwarwick]

This looks good to me, but if you haven't already can you verify this works or has a proper fall back when connecting to a legacy sg version that doesn't have the provider available in the LLM config

[chwarwick]

I assume this doesn't cause issues if the provider field does not exist?

[taras-yemets]

Great catch! How did I miss that?! Thank you, @chwarwick!
Addressed in a16c760
Honestly, I don't like the implementation. Do you know of a more robust way of getting a potentially non-existing field?

cc: @philipp-spiess

[taras-yemets]

can you verify this works or has a proper fall back when connecting to a legacy sg version that doesn't have the provider available in the LLM config

Thanks for your review, @chwarwick!
I tested this PR with the latest changes (a16c760) and can confirm it works with Sourcegraph versions without Cody LLM provider field available.