Creating Int environments

[Brendan Bergen]

While following along with Deploying an int-like development RP, I found a few bugs that I needed to hack and slash my way though. I have commits that "fix" these issues, but I wanted to get some feedback first.

1. In that doc, devs are asked to modify their local ./env by adding variables. I worry this will lead to divergent ./env file structure (for those that read this doc, and those that don't - this leads to more "works on my machine" issues). Can we move this into env.example so that every dev has the same setup from the start? Is there a better place to do this, or a reason we shouldn't?
2. Fluentbit versions are currently hardcoded in 3 unique places: in ./env, in Makefile, and in /pkg/util/version/const.go. These versions have already diverged between SEMVER and latest. We should pick a single source of truth used everywhere - where should that be?
3. make dev-config.yaml generates invalid DNS names for ACR that look something like userazurecr.io/blah instead of user.azurecr.io/blah, which is again inconsistent with where we push images with the ACR name used to generate images in ./env, which looks like useraro.azurecr.io/blah - we need a single source of truth for ACR names.
4. Finally, an external issue: the Fluentbit package repo we use only serves the most recent version of Fluentbit (today, that's 1.8.12-1, on Monday it was 1.8.11-1). If we don't have the current version set correctly, the build fails, and someone has to go in and figure out what the current version is, update fluentbit versions (today, in 3 places), and then re-run the build. I can appreciate why we hardcode versions, but this seems like toil if the only option we'll ever have is "install the latest one". I did sniff around, and you can still download the RPMs with a direct call like curl -LO http://packages.fluentbit.io/centos/7/x86_64/td-agent-bit-1.7.8-1.x86_64.rpm, even if the yum repo doesn't serve them. What's the best path forward here?