Add schema versions and dbt versions to json output

[beckjake]

Describe the feature

Add schema versions to our hologram output. I imagine we'd version them with the $schema keyword, but I'm open to using an explicit schema-version field instead.

I've separated this from #2671 as I think using $schema means we should host the schemas somewhere and that requires a bit of infrastructure-type work. Or if we don't want to host the schemas, at least requires some care when it comes to generating the URLs.

Describe alternatives you've considered

No versions! Anarchy!

Who will this benefit?

Consumers of dbt's json output.

[jtcohen6]

URL something like: schemas.getdbt.com/dbt/... We don't need to host anything there just yet.

[jtcohen6]

In a world where we have schema versions for dbt artifacts, the --state flag should raise a nice error if trying to compare against an artifact of a different version from that which the current invocation would produce. It raises a much uglier error today (slack thread).

N.B. This isn't a prerequisite to resolving the issue. It feels most relevant here and I wanted to avoid losing the thought.

[beckjake]

I've created schema URLs of this form: https://schemas.getdbt.com/dbt/{name}/v{version}.json

So for example, https://schemas.getdbt.com/dbt/catalog/v1.json

We don't happen to host those files, but we could.

For $schema, I misunderstood the spec - that refers to the json-schema schema itself. However, there is a $id field in the schema that is what I was thinking of.

I'm going to add two fields here for a certain type of object (RPC responses, catalog.json, manifest.json, run_results.json, and sources.json):

• the schema itself is going to get a $id field that is a URI. Most users won't see this (unless we choose to host it!)
• Those objects will also have a required schema property named dbt_schema_version. It will be required to be a constant of the schema's $id field. This is of course also reflected in the schema itself.

Reading an object triggers a check on the dbt_schema_version field that raises a special exception, which can be caught by dbt. dbt can catch, decorate, and re-raise that error with a filename for better error messaging.

In the future, when we implement the metadata field (#2761) we'll push that field down into the metadata, but for now it lives at the root level with most of the other metadata.