cc @bndw @moderation

LGTM. Hopefully this will help with people trying out the sandboxes and will align test images to master doco.

I think this will immediately help folks, but I wonder if the real source of the friction here is defaulting users to docs/configs/examples at the current HEAD of development, instead of an official release.

Theoretical example

Sarah grabs the latest official release of Envoy from Dockerhub, then heads to the docs for a configuration example. She grabs a simple example and immediately finds it's incompatible! Frustration ensues.

If the majority of docs/configs/examples consumers are Envoy users and not developers, it may make sense to reorganize things to prefer envoyproxy/envoy images and the release branches in Github.

To @bndw's point, we really want docs/config/examples to depend on whether the docs are cut at a release version or not. Sarah should be looking at the docs corresponding to her version, if it comes from Dockerhub at v1.9.1, then the docs should point at configs at that version.

Might need some templating that depends on the build type when the docs are generated.

I agree which is why I refer to an env variable above (templating is more accurate). Thoughts on still merging this as I think it's getting us back to where we were previously?

I opened #6361. There is a lot to unpack there and I agree with @bndw we can do better. However, I think this gets us back to where we were before so it's worth merging.