Phase out all checksums weaker than sha256 (if possible)

Contingent on: No known uses of these checksums as intrinsically important to any current plugin. [0]

I propose that we we phase out support for md5, sha1, and sha224 checksums (and maybe sha384 too) by falling back to immediate download for artifacts for which those are the only checksums available. The checksums would still, for the time being, be considered acceptable in terms of verifying the integrity of downloaded files during this immediate sync [1].

Presuming that we have no need to provide these lesser checksums as part of the plugin-specific communications APIs, that would allow us to remove these checksums from both the RemoteArtifact and Artifact models, as we would always have sha256 (and probably sha512) checksums available, which are pretty much the only ones used in practice.

This would be part of our next breaking change release as it would require prep work from plugins such as the RPM plugin.

[0] md5 and sha1 for instance are mostly used by a small number of rhel6 and rhel7 repos, and any users that want to use those repos would be well served to be downloading local copies at this point anyway. I don't know about Debian, Container, Ruby etc, though.

[1] However we could also rework the downloader such that supporting these checksum types can be delegated to the plugin (who has more knowledge of what checksum support may be needed) rather than something required by core.
This could potentially allow us to purge support for these checksum types from core entirely.

Start by auditing the RemoteArtifact and Artifact models and the downloader for uses of md5, sha1, sha224, and sha384. Review plugin-specific communications and the RPM plugin before deciding whether weaker checksums can be phased out. Done means the breaking-change scope, plugin preparation, and behavior for artifacts lacking sha256 are agreed and covered.