electron: allow accessing the metrics endpoint for performance analysis

[xai]

What it does

By default, when running Theia in Electron, all endpoints are protected by the ElectronTokenValidator.
This patch allows accessing the '/metrics' endpoint without a token, which enables us to collect metrics for performance analysis.

For this, ElectronTokenValidator is extended to allow access to the metrics endpoint. All other endpoints are still protected.

Contributed on behalf of STMicroelectronics

How to test

• Build and start the Electron example. To avoid getting a random free port on runtime, use yarn electron start --port=3000.
• Access the '/metrics' endpoint, e.g., by calling curl http://localhost:3000/metrics.
• Verify that metrics are returned.
• Access a different endpoint, e.g. http://localhost:3000/foo.
• Verify that the request is denied.

Follow-ups

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[sdirix]

This works, however we should think about whether we really want to expose the metrics endpoint by default in Electron. I think it would be more reasonable to only do the rebinding in case we are in debug or development mode. We already only collect startup metrics in development mode, so we could align with that.

Rebinding the ElectronTokenValidator will also often not have an effect in downstream projects. It's a common pattern to rebind it to allow for custom exposed APIs, so they will overwrite this one again. We should probably have a contribution point within the ElectronTokenValidator to allow contributing whitelists. Of course this is out of scope for this PR, but we should create a ticket for that.

[tortmayr]

This works, however we should think about whether we really want to expose the metrics endpoint by default in Electron. I think it would be more reasonable to only do the rebinding in case we are in debug or development mode. We already only collect startup metrics in development mode, so we could align with that.

Sounds reasonable to me. But I don`t have a strong opinion on that. I don't see any harm in exposing the metrics endpoint per default.

Rebinding the ElectronTokenValidator will also often not have an effect in downstream projects. It's a common pattern to rebind it to allow for custom exposed APIs, so they will overwrite this one again. We should probably have a contribution point within the ElectronTokenValidator to allow contributing whitelists. Of course this is out of scope for this PR, but we should create a ticket for that.

+1 I agree, rebinding the ElectronTokenValidator is not ideal. I like the idea of a contribution point for whitelisting custom API endpoints.

[xai]

Thanks, @sdirix and @tortmayr! I will revise my PR accordingly.

[tortmayr]

Looks good to me and works as expected.
One minor regarding imports but otherwise everything works.

[tortmayr]

Should either be http.IncomingMessage
or the type in allowWsUpgrade should be aligned to avoid the double import from "http".
(import * as http from 'http' and import { IncomingMessage } from 'http'; )

[JonasHelming]

@tortmayr Can you merge this?