Improve infrastructure for named pipes

[Falco20019]

This is a follow-up on #2342.

• Version: 1.3.0
• Platform: Windows 10 20H2
• Subsystem: spire-server

I sadly missed out on the switch to named pipes a month ago. Using pipes works great as long as you only use the given tools or live in a GoLang world. As soon as you try to use gRPC with named pipes in any other language, you run into issues. For C++ and related languages, it's requested since 2017 (https://github.com/grpc/grpc/issues/13447). Also popular infrastructure like https://github.com/ghostunnel/ghostunnel is only supporting tcp and unix protocols.

IMO, using named pipes seems like the right step and I don't know a better one to be honest. Just wanted to bring the limitations to everyones attention. It would be great to have a PR on ghostunnel for adding named pipe support, since it's also written in GoLang. I can have a look at it for porting it over from here. But I'm no GoLang developer and others might therefore produce better code :)

[amartinezfayo]

Thank you @Falco20019 for opening this issue. We are aware of the lack of support for named pipe transports in the C/C++ gRPC library. That was one of the reasons why we tried with TCP transport first, but then we realized that we had many other limitations with TCP that made us to switch to named pipes. Improving the integration with other language libraries is a priority for us and we plan to work on this shortly.

[Falco20019]

@amartinezfayo Thanks for your response. I created follow-up issues for bringing spiffe/go-spiffe and ghostunnel/ghostunnel up with named pipe support. Both should not be too hard to update. Especially ghostunnel is just relying on spiffe/go-spiffe which sadly still missed the support. But since it's also maintained by the same team AFAIK, you should already have an easy life implementing it :)

[Falco20019]

This can be resolved once https://github.com/ghostunnel/ghostunnel/issues/366 is merged. Thanks to @MarcosDY for supplying the PR!