[phase 4] Viper Framework

[ajm188]

This issue tracks the laying out of a standard framework of using viper within the Vitess codebase.

Motivation

Vitess is a huge codebase with lots of different areas and conventions and ways of doing things. Configuration is one of the few aspects that really, truly benefits from a consistency of expectations for both developers ("I need to add a new flag/option, where/how do I put it" and "I need to change a default value / mark something as deprecated, what's the Right Way ™️ ") and users ("I need to change/set a timeout/threshold/whatever, how can I do that" and "how do I see all the possible options").

Standardizing on some framework helps to satisfy both sides of this equation, while hopefully minimizing the costs introduced (namely: friction for net-new work; problems are harder to google ("is it the underlying viper code or the framework that's buggy"); and the full feature set of the underlying library the framework sits in front of is usually limited/hampered in some way).

Goals

• Provide a single method to configure values backed by viper instance(s).
• Provide options to provide custom getters/unmarshalers for reading values that aren't primitive Go types.
• Provide a mechanism to support dynamic config loading, making it opt-in per value (N.B. config watching/loading is not thread safe in viper, so there's an inherent cost to making it so; therefore some use cases may want to opt out of this and read a value once, or some middle ground where they periodically check if there's been a (thread safe) update to the dynamic value)
• Move in the direction of being able to fully-automate the documentation of all configuration options / flags / environment variables / defaults for all Vitess binaries.

[deepthi]

This is marked as Done, hence closing. Fixed by #11456.