Add stub of lib/teleterm VNet gRPC service

[ravicious]

This PR adds a new gRPC service to lib/teleterm. The Electron app is going to use this service to control VNet through the tsh daemon.

The RFD is still in review, but I don't expect the UI to change much. The stub and the service definition itself are very simple with just Start and Stop RPCs. I'm going to expand it with more comments as I add more stuff to it.

If you read through the UX section of the RFD, you'll see that from the perspective of Connect we don't need anything else other than Start/Stop. Information about new connections is going to flow through tshd events, but that's yet to be implemented.

What's noteworthy about this PR is that it's the first time we're adding a new service instead of cramming more RPCs into TerminalService. The cost of adding a new gRPC service is minimal (especially now after Grzegorz removed much of the boilerplate from the gRPC clients) compared to the benefits we get from separating responsibilities.

[gzdunek]

I'm curious if there is any performance difference of providing a separate transport to each service vs reusing the same one.
But we provide different loggers in the interceptors, so it wouldn't work for us anyway.

[ravicious]

Oh yeah, good point, we should probably reuse them.
I can update the interceptor to use tshd as the name but I'll make sure it logs the service name as well.

• https://learn.microsoft.com/en-us/aspnet/core/grpc/performance?view=aspnetcore-7.0#reuse-grpc-channels
• https://github.com/timostamm/protobuf-ts/blob/1798e0d43c31eafb4b5877ef72f05abb87456823/packages/grpc-transport/src/grpc-transport.ts#L30-L38

[gzdunek]

I can update the interceptor to use tshd as the name but I'll make sure it logs the service name as well.

Cool!

[ravicious]

The last two commits reuse a single transport and log service names.

I also changed the format of the logs a little bit. I went back to the old send/receive at the start of the log message which I think makes it easier to differentiate requests from responses (since it's at the start of the line). I stripped down as much characters from the message as I could and the service name is separated from the method name with a space, not with a slash. This way the console can put those two on separate lines, rather than usually just doing something like:

[tshd] info: receive
teleport.lib.teleterm.v1.TerminalService/GetCluster { … }

Now it's just:

[tshd] info: receive teleport.lib.teleterm.v1.TerminalService
GetCluster { … }

Let me know what you think.

[ravicious]

Also, I noticed that the pin sensitive property filters out pinnedResources too. 💀 idk, I guess the easiest way to solve this would be to make a list with exceptions.

[gzdunek]

Now it's just:

[tshd] info: receive teleport.lib.teleterm.v1.TerminalService
GetCluster { … }

I don't have a strong opinion, but this looks fine.
One more thing that we could do to improve readability would be to not stringify objects in the dev tools:

I was experimenting with this recently.

Also, I noticed that the pin sensitive property filters out pinnedResources too. 💀 idk, I guess the easiest way to solve this would be to make a list with exceptions.

Or simply match full property names, I'm not sure if we need to use .includes() 🤔

[ravicious]

I thought about not stringifying objects some time ago, but doesn't this conflicts with logging to a file or something? I remember I tried it a long time ago but I ran into some problems.

As for full property names, yeah, that's an option as well. I guess I initially wanted us to do substring matching just to be safe.

[gzdunek]

I thought about not stringifying objects some time ago, but doesn't this conflicts with logging to a file or something?

No, I use different "logging transports" for the file and for dev tools. I will open a PR for that in some spare time
(and fix the bug with filtering "pinnedResources").

[gzdunek]

Thanks for reusing the same transport.

Would it be okay for you to wait for #39828 to be merged first? It will make my life easier when backporting that PR to branch/v15.
I'm going to do it in the morning.