It looks like the `foregroundDeletion` finalizer that gets added to the
GameServer when a deletion with foreground propogation is requested -
when it gets removed, by the Kubernetes system, the ResourceVersion/Generation
doesn't get incremented.

This means when we do an `Update` it will go through (usually it fails if the
ResourceVersion/Generation has changed since the last update), rather than
failing and going back to re-sync.

This can cause a race condition where the `Update` can basically put back
the `foregroundDeletion` finalizer, if it gets removed between retrieving the
`GameServer` object and doing the `Update()` operation.

We actually don't need the `foregroundDeletion` propogation on `Delete()`, as
we only want to keep the `GameServer` around until the backing `Pod` is gone,
so we can actually just turn this off instead in the code.

As a note - also explored using a `Patch()` operation to try and solve this
problem. AFAIK, a patch (and specifically a JSONPatch - other patch types
didn't seem better), can only do index based removal from a list of items.

This could just present other types of race conditions, as finalizers could
be added/removed by other systems at the same time as well, changing the index
to the finalizer we want at the same time.

Not sure if this is a bug in the Kubernetes system, or working as intended,
but this solves the issue.