Proposal: environment variable for experiments and compatibility

[jba]

Once this module is at v1, we won't make any breaking API changes. But we may make slight behavior changes. For example, our streaming transport implementation may return more fine-grained HTTP status codes to help clients distinguish different types of errors, or we might turn some code paths that are currently successful into errors if they violate the specification or they inevitably lead to errors further on. We want to give users time to adapt their implementation to these changes.

We also may conduct experiments, adding new features that we're not sure are the right ones, or have the right API. We want to allow users to opt in to these experiments.

We propose to provide for both of these cases with an environment variable, GOMCPSDK. Its value will be a comma-separated list of key=value pairs. Each entry will either restore old behavior or enable an experiment.

The README for the module will document the each entry and, for compatibility-preserving entries, when they will expire. A typical compatibility entry will expire after one minor version has passed, locking in the new behavior. For example, an entry introduced in v1.3 will be removed in v1.5.

[findleyr]

I'm in favor of this, though we can hold off on implementing it until we have a need.