Support Agones sidecar Windows build

[alexandrem]

Windows 1709 supports LCOW (linux container on Windows) and sharing the pod with linux and Windows containers side-by-side. Containers also share the same network namespace.

This would allow deploying Agones on a Kubernetes Windows node with the main game server in a Windows container.

However, this requires Hyper-v with nested virtualization. This makes deployment options more complicated, either on-prem or on external providers. Some compute providers supports 1709 Windows images, but it's not clear which ones support nested virtualization.

Agones sidecar doesn't seem to have much assumptions about running on a linux node.

Ideally, the sidecar should be cross-platform and also have a Windows build version, using either microsoft/windowsservercore:1709 or microsoft/nanoserver:1709.

Some limitations right now is that service account tokens do not work well on Windows containers, so this needs to be resolved to have the token injected correctly by kubelet:

kubernetes/kubernetes#52419

This issue is related to the Windows support discussed here #54

[markmandel]

Worth noting - right now that the sdk sidecar already builds a binary for windows:
https://github.com/googleprivate/agones/blob/master/build/Makefile#L137-L138

And will be part of the upcoming release binaries.

So that step is already solved (assuming no bugs have been found).

I'm going to assume we need Windows to create a Windows container image, and I'm also not aware of where one stores a Windows container image?

[cyriltovena]

grc should be fine, but the gcp build system probably doesn't support windows docker. I could push manually for now.

[alexandrem]

We can add AppVeyor automated build in the github project once Agones is public.

[markmandel]

I think we should add AppVeyor anyway once Agones is public, because then we can also do static + dynamic libs for the C++ sdk on windows

[EricFortin]

Quick note on this, there are limitations on Windows container that requires building an image for exact Windows version of target host. That means we would have to create multiple images(from multiple build runner running different Windows versions) and/or use multi-arch images.