Feature/Update zync controller

[slopezz]

Solves part of https://github.com/3scale/platform/issues/235

• Remove zync init container (there was an init container which just check basic DB connectivity, just present on zync deployment, while both deployments connect to same postgres DB). We are removing that kind of init containers from 3scale saas, as DB connectivity is always needed, not just on pod startup. Actually, on a possible rolling update process, if there is no DB connection, new pods won't pass liveness/readiness healthchecks, so new pods won't be promoted for example.
• Remove var dbWaitSleepSeconds (was only used on removed init container)
• Match default number of replicas to current documentation
• Document only accepted value on railsEnv var (test/development/production), leave default value to development), otherwise when pod starts it complains about:

onfig.eager_load is set to nil. 
Please update your config/environments/*.rb files accordingly: 
* development - set it to false 
* test - set it to false (unless you use a tool that preloads your test environment) 
* production - set it to true

• Remove possibility to change railsLogsToStdout: 3scale product already enables it by default and cannot be tuned, it seems it just changes the logger format, and there is no reason to not have it always enabled. In addition, it is only used on production environment (RAILS_ENV=production), which is the only environment value possible for serious zync deployments (staging/production...), because it enables all zync features. Actually, although it is used as a boolean, zync app just checks if var is present, independently from the value.

[miguelsorianod]

Remove zync init container (there was an init container which just check basic DB connectivity, just present on zync deployment, while both deployments connect to same postgres DB). We are removing that kind of init containers from 3scale saas, as DB connectivity is always needed, not just on pod startup. Actually, on a possible rolling update process, if there is no DB connection, new pods won't pass liveness/readiness healthchecks, so new pods won't be promoted for example.

Original motivation of the init container was to prevent the pod from crashing at startup time. When deploying 3scale, customers temporarily saw pods crashing (due to DB not available because it's booting up, and zync process crashing when it's not available) and being restarted until DB connectivity was available, which was perceived as "unstability" of the deployment from their given feedback (pods in 'red', crashing and restarting until their dependencies were available, etc.).

[raelga]

Nice improvement, lgtm!