Add v1alpha1 generated protos

[johanstokking]

Summary

Closes #1

Changes

• Add tooling to generate code from protos
• Generate v1alpha1 per packetbroker/api@b937aab (not merged, hence draft)

Notes for Reviewers

Please have a look at the tooling and how things are being generated, like this one https://github.com/packetbroker/go-api/pull/2/files#diff-f6797f8393b8812416981fa126276a50

We don't have version dependencies for protoc and gogofaster. The only way to do that right seems to be what we do in The Things Stack, but I consider that overkill for now.

[htdvisser]

1. I don't think the tooling really matters at this point. I think it's important to choose between golang/protobuf and gogo/protobuf because that will have implications for all server and client implementations, and as a consequence, will be relatively difficult to change in the future, although that would be fine for v1alpha2 and later, since those will have a different import path anyway.
2. The protoc indeed doesn't make much of a difference, but the version of the Go generator tends to change. I explored this in a sideproject and decided to try a go generate that downloads and installs (see generator.go) the dependencies and tooling (see tools.go). Because it's in a Go module, those will be the version that I expect.
3. We may want to put go.mod in v1alpha1

[htdvisser]

protoc-gen-gogofaster eliminates XXX_unrecognized fields, which I think we should keep for forwards compatibility.

[johanstokking]

protoc-gen-gogofaster eliminates XXX_unrecognized fields, which I think we should keep for forwards compatibility.

Yeah I considered this. It can cause unwanted side-effects in the future, for example when storing marshaled protos that may change future behavior and validation. I'm neutral, I don't see the benefit. Clients should be explicitly talking to a versioned API endpoint anyway.

[htdvisser]

I was more thinking about supporting a chain of forwarders that have slightly different versions. If we add a response field to the API (assuming it doesn't change behavior) it would be nice if that field wouldn't be dropped by a forwarder that isn't updated yet.

[johanstokking]

But that means that an intermediate forwarder receives messages from v1alpha2 and sends it as v1alpha1; those are not compatible anyway, right? When mapping those types, the v1alpha2 specific fields get lost, but I'm not sure in which case we could retain that realistically? Copying XXX_unrecognized?

[johanstokking]

I think we can resolve this later