If a temporal service fails to start due to a missing config key, log the missing key

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
When creating a kubernetes deployment of temporal, a customer ran into what looks like a configuration problem, which manifested itself in the service simply exiting, with the following log:

2020-06-15T15:12:00.852003855Z + bash /start-temporal.sh E 
2020-06-15T15:12:00.854018920Z + dockerize -template /etc/temporal/config/config_template.yaml:/etc/temporal/config/docker.yaml E 
2020-06-15T15:12:00.857719185Z + exec temporal-server --root /etc/temporal --env docker start --services=frontend E 
2020-06-15T15:12:00.875540906Z 2020/06/15 15:12:00 Loading config; env=docker,zone=,configDir=/etc/temporal/config E 
2020-06-15T15:12:00.875686932Z 2020/06/15 15:12:00 Loading configFiles=[/etc/temporal/config/docker.yaml] E 
2020-06-15T15:12:00.876097429Z 2020/06/15 15:12:00 Config file corrupted.yaml: line 123: did not find expected key E

debugging the condition was tricky, and could be greatly simplified if only the log included the name of the missing key.

Describe the solution you'd like
A clear and concise description of what you want to happen.

When validating configs and encountering a missing key, please include the. name of the key in the log.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

The obvious (default) alternative is to do nothing. which is also fine, but makes problems harder to troubleshoot.

Additional context
Add any other context or screenshots about the feature request here.

This problem was brought to my attention by Ringo in Temporal slack chat: https://temporalio.slack.com/archives/CTTJCPZQE/p1592235043052000

Start by tracing configuration loading and validation from the temporal-server startup command, using the shown /etc/temporal/config/docker.yaml and config_template.yaml paths as context. Confirm where a missing key is detected and make the completed behavior include that key in the startup log, then verify the resulting diagnostic against the reported failure.