What happened: om-backend misbehaves and refuses to create allocations if the assignedDeleteTimeout configuration setting is left unset.

What you expected to happen: If this setting is critical, om-backend should crash on startup rather than 100% erroring during allocation request creation. Similar behaviour should be applied to any other setting that must mandatorily be set for good behaviour.

How to reproduce it (as minimally and precisely as possible): Create an openmatch setup and make sure assignedDeleteTimeout is omitted

Anything else we need to know?: This setting is always populated by the helm charts, however, we have been using openmatch for a while and as such we simply kept the config files that had been generated several versions ago.

Output of kubectl version:

╰─ kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.11-gke.5", GitCommit:"baccd25d44f1a0d06ad3190eb508784efbb990a5", GitTreeState:"clean", BuildDate:"2020-06-25T22:55:26Z", GoVersion:"go1.13.9b4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): GKE

Open Match Release Version: 1.0

Install Method(yaml/helm):: helm but with our own config files and bazel wrapping