Declare compatibility for previous artifact versions

[jtcohen6]

resolves #5213

Description

We've been very aggressive about bumping artifact versions any time the artifact schema changes. For manifest.json, that's meant a bump for every minor version thus far, even when the schema changes are very minor (hah).

Sometimes, those changes do make it impossible for the latest version of dbt to deserialize an older manifest. Sometimes, they don't, and dbt can use the previous manifest version happily. These cases deserve different treatment, but today, we raise a version mismatch error in all cases.

This PR:

• Develops the capability to differentiate between compatible and incompatible manifest versions, via a new base artifact class method is_compatible_version
• Adds manifest v4 (produced by v1.0) to the set of "compatible" versions
• Adds a functional test case

Very open to feedback on the implementation and nomenclature. If it's something we can feel good about, I'd really like to backport it to 1.1.latest for inclusion in an upcoming v1.1 patch (probably v1.1.2), since this will ease the migration path for v1.0 → v1.1 for anyone who uses state:modified / the "Slim CI" feature.

Checklist

• I have read the contributing guide and understand what's expected of me
• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
• I have run changie new to create a changelog entry

[gshank]

This looks like a nice neat solution to me.

[ChenyuLInx]

The changes look good to me!
One question that doesn't affect the merge of this PR: is it possible to automatically check compatibility by loading the manifest so that we don't need to always define it? But feels like that would have more drawbacks then benefits

[jtcohen6]

is it possible to automatically check compatibility by loading the manifest so that we don't need to always define it? But feels like that would have more drawbacks then benefits

Yeah, I'd rather just keep it simple here, and test the end-user experience as closely as possible by including the actual contents of an actual manifest. It's not a guarantee that this will work in all cases, since this manifest is for a very simple project, but I hope that it would catch most errors that would arise during deserialization. It's also possible that the version upgrade has changed underlying dbt behavior, such as a core built-in macro, thereby triggering many many resources to rerun during "Slim CI."

I'm going to hold off on merging and backporting this PR until we've cut the final release of v1.1.1 (currently available as RC2).