Fix don't swallow the error when building zap logger

[git-hulk]

What changed?
Fix don't swallow the error when building zap logger

Why?

Currently, start the cadence server would be panic when
failed to build the zap logger. It will cause confusion since
the error was swallowed.

How did you test it?

test local with no permission log dir

Potential risks
no

[meiliang86]

log fatal or panic here in case of error?

[meiliang86]

I guess you don't have a logger, so the only thing you can do is to panic

[git-hulk]

Yeah, I have used the ErrorAndExited to log the error and exit

[coveralls]

Pull Request Test Coverage Report for Build 6f97086c-b2ec-43a0-84a0-eedca1d3a7df

• 2 of 18 (11.11%) changed or added relevant lines in 5 files are covered.
• 80 unchanged lines in 13 files lost coverage.
• Overall coverage decreased (-0.02%) to 67.963%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
bench/lib/context.go	0	1	0.0%
canary/runner.go	0	4	0.0%
tools/cli/domainUtils.go	0	5	0.0%
cmd/server/cadence/server.go	0	6	0.0%

Files with Coverage Reduction	New Missed Lines	%
common/task/weightedRoundRobinTaskScheduler.go	1	89.64%
host/signalworkflowTest.go	1	95.53%
service/history/execution/mutable_state_task_refresher.go	1	75.29%
common/persistence/cassandra/cassandraPersistenceUtil.go	2	92.62%
common/persistence/executionStore.go	2	73.9%
common/task/fifoTaskScheduler.go	2	87.63%
service/history/execution/mutable_state_builder.go	2	69.85%
service/history/task/transfer_standby_task_executor.go	2	90.77%
service/history/queue/processor_base.go	7	61.82%
service/history/shard/context.go	8	61.88%

Totals
Change from base Build 57b85506-5696-4904-9735-e8a190fcf0ff:	-0.02%
Covered Lines:	98645
Relevant Lines:	145146

---

💛 - Coveralls

[Groxx]

Huh. Why don't we have this passed in? Constructing a logger seems doomed to be over-complicated (as we expose more and more logger-configuration fields) and less flexible (zap loggers can do effectively anything, there's no reason for us to limit them).

Accepting a logger would also simplify the log, _ := config.NewZapLogger() case in tests: pass in a zaptest.NewLogger(t) instead of constructing one and trying to work around the test environment.

[longquanzheng]

Huh. Why don't we have this passed in? Constructing a logger seems doomed to be over-complicated (as we expose more and more logger-configuration fields) and less flexible (zap loggers can do effectively anything, there's no reason for us to limit them).

Accepting a logger would also simplify the log, _ := config.NewZapLogger() case in tests: pass in a zaptest.NewLogger(t) instead of constructing one and trying to work around the test environment.

Which one are you referring to? I think we have to do this way because they are in from different main() : server, bench, canary and CLI. So we can't pass a logger from server to cli code, hehe.
Or in other words, we already try the best to pass around/initiate only once.

[longquanzheng]

@Groxx I merged this PR but if you see a way that we can improve by passing around logger, we make do a refactoring