refactor: foundations for LSP workspaces support

[ematipico]

Summary

Related to #1573

This refactoring doesn't change any logic, but it does some internal refactoring to prepare the LSP to support multiple workspaces.

I created some data structures to help to query/mutate the workspaces.

To save the workspaces data, I used slotmap::DenseSlotmap. You can read more in the documentation.

The good about slotmap is that it emits a unique key every time we insert something; that key can be used later on to access the stored data. Those keys are always unique. Also, upon deletion, the slot that was used stays free, and it gets reused when a new element is inserted.

I chose DenseSlotmap because it's the fastest during iteration and slowest upon insertion. Inserting workspace folders will be a one-time operation or a rare operation. How many times does a user add a new project to a workspace? However, choosing the correct workspace will be an operation that we will have to do often. The LSP isn't able to signal if a file belongs to a certain workspace, so we have to guess it based on its path.

Test Plan

The current tests should pass

[codspeed-hq]

CodSpeed Performance Report

Merging #2589 will create unknown performance changes

_{Comparing feat/lsp-workspaces (dccb988) with main (dc7cb57)}

Summary

🆕 93 new benchmarks

Benchmarks breakdown

	Benchmark	main	feat/lsp-workspaces	Change
🆕	analyzer[css.js]	N/A	84.8 ms	N/A
🆕	analyzer[index.js]	N/A	186.8 ms	N/A
🆕	analyzer[lint.ts]	N/A	160.4 ms	N/A
🆕	analyzer[parser.ts]	N/A	299.3 ms	N/A
🆕	analyzer[router.ts]	N/A	84.5 ms	N/A
🆕	analyzer[statement.ts]	N/A	268.7 ms	N/A
🆕	analyzer[typescript.ts]	N/A	431.6 ms	N/A
🆕	bootstrap.css[cached]	N/A	257.6 ms	N/A
🆕	bootstrap.css[uncached]	N/A	283.2 ms	N/A
🆕	bulma.css[cached]	N/A	247.9 ms	N/A
🆕	bulma.css[uncached]	N/A	267.9 ms	N/A
🆕	foundation.css[cached]	N/A	165.2 ms	N/A
🆕	foundation.css[uncached]	N/A	178.6 ms	N/A
🆕	full.css[cached]	N/A	2.5 s	N/A
🆕	full.css[uncached]	N/A	2.7 s	N/A
🆕	materialize.css[cached]	N/A	180.8 ms	N/A
🆕	materialize.css[uncached]	N/A	202.2 ms	N/A
🆕	pure.css[cached]	N/A	21.6 ms	N/A
🆕	pure.css[uncached]	N/A	25.1 ms	N/A
🆕	semantic.css[cached]	N/A	753.7 ms	N/A
...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

[arendjr]

So these two get_settings_by_path methods seem to be the only places where we iterate over the paths, and I don't the methods being used anywhere. Do we anticipate that they will be commonly used going forward?

I'm asking because the DenseSlotMap was chosen because of fast iteration, but at least as of yet we don't do any iteration yet. Based on the current state that would not make it a good choice, but that could change if these methods become the most commonly used ones in the future.

[ematipico]

I remove two functions and kept only one: get_settings_by_path.

As mentioned in the description, in the LSP there's way to retrieve the current project when handling a file. When the LSP sends us the request textDocument/didOpen, we only get its absolute URL.

In order to understand if a user opened a file that belongs to a different project from the previous, we need to inspect its path, and that's where the iteration will come into play.

If you come up with a better solution by the time I will open the next PR, that would be awesome.

[arendjr]

👍