There was a race condition in the original
implementation. This fixes that issue!

(and makes the code cleaner!)

Realised that all the new Rust SDK code
didn't have the Apache licence applied.

This applies the licence.

Change the Xonotic example to have wrapper
around the server execution, and use the
content of stdout to determine what to do
with the SDK for GameServer lifecycle management.

This implements a configurable rolling update strategy
for Fleets that also ensures that Allocated GameServers
are not interuppted.

Also includes updates to documentation.

Closes #70

Fixes #178

When the template for a Fleet is edited,
a deployment strategy can be defined. At the
moment, this is just the `Replace` strategy, which
terminates all current non-allocated GameServers
and immeadiately starts up new GameServers to replace
them.

Includes documentation as well.

This implements the FleetAllocation CRD, that when created
looks at the requested Fleet, and marks one of the
GameServers as Allocated (if available) and returns it's value
in the FleetAllocation.

This also includes a quickstart and spec for reference as well.

Some refactoring was included in the PR (probably should have been
a seperate PR for that).

All this commit is doing is create a GameServerSet
when a Fleet is created. Also, if the Replicas in
a Fleet are updated, then the owned GameServerSet's
Replicas are also updated.

For this commit, we are not worrying about handling
updates to the Spec (e.g. new image) to the Fleet,
and doing updates to a live Fleet, we are just concerned
with scaling up and down.

Parent ticket: #70

GameServerSets are the basic building block for Fleets.
GameServerSets will be allow Fleet migrations to occur, similarly
to how ReplicaSets allow Deployments to migrate one image type
to another.

This has not been formally documented, as this will likely be an
internal CRD, and not (widely) used externally.

Parent ticket: #70

* fix misspell
* add err check and fix var shadowing
* fix crd package comment

Security issue with `go get` in 1.9.3

This also includes a change on the domain to agones.dev,
and changing the name of the hosting project
infrastructure.

Closes #4

This includes updates to the SDK, and
controller code to manage the health
lifecycle of a GameServer.

Examples have also been updated, as well
as some basic documentation.

Closes #15

You can now develop Agon, and deploy Agon to minikube
for local testing and development.

The major issue was that Minikube doesn't expose the
ExternalIP for the Node it runs - so Agon will now
fallback to the InternalIP (with a warning) if it can't
find the ExternalIP.

*Breaking change* - Agon build tools will now look in
~/.kube (like all other kubernetes tools) for Kubernetes
credentials. This was to streamline auth of minikube and other
Kubernetes clusters by conforming to what Kubernetes tooling
usually expects. If you are running a GKE cluster, you will
need to run `make gcloud-auth-cluster` again to re-download
the kubectl credentials.

Closes #30

Implementation of a PortAllocator that ties into the
GameServer controller that will allocate a port on
GameServer creations (if "dynamic" portPolicy is set)
and then also release the port when a GameServer has been
deleted.

This also includes experimental support for node adding,
removal and unscheduling within the cluster.

Closes #14

This includes a very basic "server" that
integrates with the SDK to show how it works
as well as expansion of the SDK docs to explain
how they work.

This also includes working the SDK code gen
and compilation (on linux at least) into the
main build process as well.

Closes #7

and run an actual game on Agon.

Closes #18

First implementation was done in Go as prototyping.
Implementation is done with gRPC so it should be
relatively trivial to generate new SDKs for each
language.

Implemented gRPC sidecars server to accompany the SDK
and processing of the change in states, such that the
IP and Port of the GameServer is available in the
GameServer status when its status is Ready.

Closes #16

This is much better, as it allows more control over
the Pod.

This includes changes to the definition of a GameServer and the
data that is stored against it, as well as functioanlity for
setting default values on the GameServer.

To start this will be a tool for testing GameServer connections as they
as created as CRDs in Kubernetes. As we move through further
development, this will become the place where the SDK integration
will form, and finally be an example for.

This implementation just builds the basic foundation of the controller
for this Custom Resource Definition. It will check and see if the
CRD has been defined, and it not, create it in the Kubernetes cluster
it resides in, and wait until it reached an Established state.

Then it just blocks until it gets told to terminate via a process signal.