Define a repo policy for referencing specific software versions

[mthalman]

As described in #1264, there is a maintenance burden when referencing specific software versions from within the Dockerfiles of this repo. A policy should be documented that describes the patterns and practices that should be used to mitigate that burden.

Ideas:

• When possible, prefer to install via package manager without specifying a version.
• For semantically versioned software, prefer to get the latest minor/patch of a specific major version.
• Use consistent versions across all Dockerfiles where appropriate.
• Use dynamic logic within the Dockerfile to determine the latest version (example). This may be mitigated by Centrally define versions that can be used by multiple Dockerfiles #1267 if that version was to be injected into the Dockerfile or passed as an arg.
• What is the process for upgrading the major version? Need to account for breaking changes when updating versions. Which assets do we install that are the most likely to be affected by this? How do consuming repos validate upgraded versions ahead of time?
• Should a tool like Renovate be used, when possible, to keep versions updated?
• How do we keep track of whether a particular software product is EOL? We keep track of that, at a team level, for operating systems, but not things like frameworks and tools that are installed in these Dockerfiles. We really just rely on vulnerability reports. Is that sufficient? Should versions be upgraded proactively? Using https://endoflife.date may be helpful here. This is also related to Centrally define versions that can be used by multiple Dockerfiles #1267.
• What systems can be put in place, either by patterns or infra, to prevent version reference "violations" from occurring in newly added Dockerfiles?