added(webviews): Adds protocol based webview loading (CODY-3536)

[jamesmcnamara]

Adds protocol based webview loading by calling into the extension client via readUriUTF8. This way the extension can dynamically produce the webview assets without them needing to exist in a shared directory on disk.

However this currently only works for the index.html file. The other assets are relativized here and I can't think of a good way to support relativizing those paths to support them same protocol.

My first attempt looked like adding:

if (this.delegate.assetLoader === 'webviewasset') {
    return localResource.with({ scheme: 'webviewasset' })
}

but then the extension client would need to implement some behavior to capture those requests triggered by something like

<script type="module" src="webviewasset://index.js"></script>

which at least in Eclipse wasn't trivial.

Currently I just leave all relative links in place if the webviewasset loader is specified like:

<script type="module" src="./index.js"></script>

and rely on the extension client to be running some sort of asset server that will capture those requests but that's a sneaky bit of undocumented dependency.

Test plan

Ran with local Eclipse build of this branch after deleting all on-disk webviews and confirmed it was served.

Changelog

Allows dynamic serving of webview assets from non-VSCode clients

[dominiccooney]

First up, I don't know what the motivation for this change is. I could guess but I won't. If I understood that better I could probably help more.

With that said, on the face of it, let's not do this.

What's the benefit? Agent/client already need to know where Agent's index.js is on disk... so what if the webview resources come from the filesystem or not?

We don't want resource URIs like webview:// because (I assume) CSP won't understand they are secure.

It is another divergence from VSCode.

It has the potential to make JetBrains CODY_DIR development a different now, because in one case the resources are on disk and in this other case, they're...?

It could be integrated at the webview layer with less effect on the extension code. The native webview provider can give a prefix string when it sets capabilities, and the extension can use the VSCode API's URL rewriter to rewrite to it, without the branching added here.