[Bug] [LSP] Case-insensitive URIs are used for text document management and synchronization notifications

Reproducible in vscode.dev or in VS Code Desktop?

• Not reproducible in vscode.dev or VS Code Desktop -- untested

Reproducible in the monaco editor playground?

• Not reproducible in the monaco editor playground

Monaco Editor Playground Link

Monaco Editor Playground

Monaco Editor Playground Code

const value = /* set from `tm`: */ `
def fibonacci(n):
    a = 0
    b = 1
    
    # Check if n is less than 0
    if n < 0:
        print("Incorrect input")
        
    # Check if n is equal to 0
    elif n == 0:
        return 0
      
    # Check if n is equal to 1
    elif n == 1:
        return b
    else:
        for i in range(1, n):
            c = a + b
            a = b
            b = c
        return b

print(fibonacci(9))

fibonacci(4)`;
monaco.languages.register({ id: 'python' });

const tm = monaco.editor.createModel(value, 'python', 
	monaco.Uri.parse('file:///d:/dev/MixedCase.py')
);

const editor = monaco.editor.create(document.getElementById('container'), {
	model: tm,
	language: 'python',
	theme: 'vs-dark',
});

// In this playground, we cannot directly load the worker
const PYRIGHT_WORKER_URL = "https://cdn.jsdelivr.net/npm/@typefox/pyright-browser@1.1.299/dist/pyright.worker.js";
const bootstrap = `importScripts(${JSON.stringify(PYRIGHT_WORKER_URL)});`;
const blob = new Blob([bootstrap], { type: "application/javascript" });
const workerUrl = URL.createObjectURL(blob);

const worker = new Worker(workerUrl);
worker.postMessage({ type: 'browser/boot', mode: 'foreground' });
const s = monaco.lsp.createTransportToWorker(worker).log();
new monaco.lsp.MonacoLspClient(s);

Reproduction Steps

This can be reproduced in the monaco editor playground with the latest version and a file URI that has mixed case: Monaco Editor Playground. When you trigger some auto-completion (Ctrl+Space) and open up the developer console, you'll see these logs:

-> [0@[object Worker]] {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"python","uri":"file:///d:/dev/mixedcase.py","version":1,"text":"\ndef fibonacci(n):\n    a = 0\n    b = 1\n    \n    # Check if n is less than 0\n    if n < 0:\n        print(\"Incorrect input\")\n        \n    # Check if n is equal to 0\n    elif n == 0:\n        return 0\n      \n    # Check if n is equal to 1\n    elif n == 1:\n        return b\n    else:\n        for i in range(1, n):\n            c = a + b\n            a = b\n            b = c\n        return b\n\nprint(fibonacci(9))\n\nfibonacci(4)"}}}
[...]
-> [0@[object Worker]] {"jsonrpc":"2.0","id":3,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///d:/dev/MixedCase.py"},"position":{"line":25,"character":12}}}

Note that the textDocument/didOpen uses URI file:///d:/dev/mixedcase.py whereas textDocument/completion uses file:///d:/dev/MixedCase.py.

Actual (Problematic) Behavior

The TextDocumentSynchronizer in the LSP API uses lower case URIs do identify text documents, cf. https://github.com/microsoft/monaco-editor/blob/613524bdf43891f71ce0bf1f99584b666d70c95a/monaco-lsp-client/src/adapters/TextDocumentSynchronizer.ts#L56 and even sends some request (textDocument/didOpen, textDocument/didChange, textDocument/didClose) with lower case text document URI whereas others are sent with the URI as specified. This can lead to wrongly managed resources on the language server side where text document URIs are rightfully considered case-senstive for the most part, as according to the language server protocol and the corresponding RFC 3986 for URIs:

[...] the scheme and host are case-insensitive [...] other generic syntax components are assumed to be case-sensitive [...].

Expected Behavior

The given URI is not changed besides the allowed normalization of the scheme and host.

Additional Context

No response

Start with monaco-lsp-client/src/adapters/TextDocumentSynchronizer.ts, especially the URI handling around the linked line, and reproduce the mixed-case file URI in the Monaco Editor Playground. Trace the didOpen, didChange, didClose, and completion messages, then verify that only scheme and host normalization occurs and the emitted document URIs remain consistent.