ep: Cap identifiers for LSP context retriever

[osyvokon]

Release Notes:

• N/A

[aviatesk]

Glad to see adding the cap here. This is definitely an improvement.

One concern is that even with this cap, the current implementation can still issue up to roughly 64 definition-related LSP requests at the same time per context refresh, which means edit predictions currently assume that all language servers can handle bursts of definition/typeDefinition requests cheaply, but that is not true for every server. Because of that, I think it would be better if this cap were configurable. Alternatively, if 32 is considered universally safe, we would need to validate that experimentally across language servers, but that does not seem very realistic.

Relatedly, given this constraint, I’d also like to see #56055 move forward. That PR fixes a logic bug where users who have disabled edit predictions due to this LSP server burst issue can still accidentally trigger edit-prediction-related definition request burst by using the "go to diagnostic" command.

[osyvokon]

edit predictions currently assume that all language servers can handle bursts of definition/typeDefinition requests cheaply, but that is not true for every server.

@aviatesk, that's a good point. I'll think what we can do here. As the first step, we'll run an LSP benchmark and/or add relevant telemetry. Then we can add an allow list for servers where typeDefinition is cheap enough. Or maybe cap LSP requests dynamically based on actual latency.