support SkipOrchestratorDatabaseUpdate

[shlomi-noach]

Storyline: #84

This PR re-introduced the SkipOrchestratorDatabaseUpdate (bool) configuration parameter.

When running multiple versions of orcehstrator, this can be useful: orchestrator marks the backend database schema with last known deployed version. Whenever an orchestrator instance runs, that is of a different version, database schema gets rebuilt. With this flag one can control the identity of the orchestrator hosts that dictate database schema.

Normally, users would not use this flag. On very large deployments this would prove useful.

cc @sjmudd

[sjmudd]

Looks good to me. Thanks.

[shlomi-noach]

Also added PanicIfDifferentDatabaseDeploy -- bail out if db version is not what the app expects. This complements SkipOrchestratorDatabaseUpdate's behavior.

cc @sjmudd

[sjmudd]

Excellent. Thanks for the PanicIfDifferentDatabaseDeploy. Most helpful. Will keep out of date clients "out of harms way" which is good.

[shlomi-noach]

Actually I was wrong and didn't look carefully at the code. SkipOrchestratorDatabaseUpdate isn't really needed:
The orchestrator backend DB records all db deployments, not just the last one. It's OK (assuming migrations are backwards compatible) to have multiple clients connecting with different versions: each orchestrator will notice its own version is already deployed and will not give it another try.

@sjmudd The Great Exodus of Variables is an effort to eliminate unneeded variables. I'm in favor of throwing away SkipOrchestratorDatabaseUpdate (again... 😛 ). What do you think?