re-fix configuration provider initialization

[sailingKieler]

This change restores the original configuration provider initialization approach contributed in #519.

To be tested:

• Proper application of the langium.build.ignorePatterns during workspace init of the grammar language server (see

  langium/packages/langium-vscode/src/language-server/grammar-workspace-manager.ts

  Lines 33 to 38 in 1bc7009

  	override async initializeWorkspace(folders: WorkspaceFolder[], cancelToken = Cancellation.CancellationToken.None): Promise<void> {
  	const buildConf: WorkspaceManagerConf = await this.configurationProvider.getConfiguration('langium', CONFIG_KEY);
  	const ignorePatterns = buildConf.ignorePatterns?.split(',')?.map(pattern => pattern.trim())?.filter(pattern => pattern.length > 0);
  	this.matcher = ignorePatterns ? ignore.default().add(ignorePatterns) : undefined;
  	return super.initializeWorkspace(folders, cancelToken);
  	}

  ), expected default values are defined here: https://github.com/eclipse-langium/langium/blob/main/packages/langium-vscode/package.json#L69-L78.
  --> Looks good AFAICS.

[spoenemann]

The changes look good to me. @dhuebner could you test this with the grammar language?

[msujew]

All of this starts feeling very convoluted. I think this change is a symptom of another problem in our language server logic. I'd like to present a different flow of data to improve on this and clean up the implementations a bit:

1. Make both initialized methods async again
2. Add ready promises to the ConfigurationProvider and WorkspaceManager interfaces. These are resolved as soon as the configuration is available and the workspace has been loaded (but not built!) respectively.
3. Await these promises at the appropriate times (i.e. for example in the textDocument/didChange handler) to ensure that everything actually waits for the required/expected events before continuing their work.

What is your opinion on that @sailingKieler and @spoenemann? This PR in its current implementation very much feels like a workaround for design issues in our language server, instead of an actual improvement. Especially the "switch the configuration and workspace manager initialized calls around" smells like a badly designed system to me. That should never be the fix in a system that is well designed.

[sailingKieler]

Especially the "switch the configuration and workspace manager initialized calls around" smells like a badly designed system to me. That should never be the fix in a system that is well designed.

Actually, the order shouldn't matter.
@spoenemann switched and fixed the invocations here, and I just flipped them back for testing purposes (and a bit because of the ConfigProvider shouldn't depend on anything, while the WorkspaceManager might depend on the former), and committed that by accident.

[msujew]

@spoenemann switched and fixed the invocations here

I know, and I wasn't a big fan of that either, it was just merged before I was able to complain about it :)

[spoenemann]

Switching was not the fix, removing await was the fix. In the general case, there is no dependency between WorkspaceManager and ConfigurationProvider. Languages that need the configuration to initialize the workspace can just use ConfigurationProvider, which awaits its initialization before returning a value.

Await these promises at the appropriate times (i.e. for example in the textDocument/didChange handler) to ensure that everything actually waits for the required/expected events before continuing their work.

That sounds good to make this logical dependency more explicit.

I propose to merge this and add Mark's proposal in a follow-up PR.