Configs in schema files

[gshank]

resolves #2401

Description

This adds the ability to set configs in schema files for models, seeds, snapshots, and analyses. It does not address configs in macros, sources, or tests, which will be addressed separately.

Checklist

• 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 updated the CHANGELOG.md and added information about my change to the "dbt next" section.

[gshank]

Notes on implementation:
I moved the add_patch, add_macro_patch, and add_source_patch code into the schema parser file because they were more appropriate there.
I changed the 'render_test_update' code for unique and not_null to make better use of the 'update_parsed_node_config' method.
I added a 'meta' attribute to NodeConfig because there were not very many code implications. The node level meta and the config meta should now be the same.
I also removed the 'vars' config attribute because it was deprecated quite a while back.

[jtcohen6]

This is great work! I had a lot of fun taking this for a spin. We'll want to significantly revise our documentation on nodes vs. properties, and that's a good thing :)

I'm going to spend some more time playing around with this. For the moment, my biggest comment is that we should merge node.config.meta into node.meta. It doesn't make sense to leave these as separate, unrelated values. This might have some confusing behavior, so let's find ways to do reasonable things. I'm thinking we should treat the meta key in the models dict as being at the "same level as" the config.meta key, and raise an error if both are set. For example:

models:
  - name: my_model
    meta:
      something: blabla
    config:
      meta:
        something: lala

We should raise an error here, since we don't know whether to prefer blabla or lala. We should do it even if those meta dictionaries contain different keys. Any in-file config(meta = ...) should take precedence.

I'm also going to open some follow-on issues that are outside the scope of this specific PR, related to the larger reconciliation effort proposed in #2401 and kicked off here.

• Support config: on tests. That might get us "for free" the ability to set the meta property on tests (Add support for meta in tests #3629)
• Support config: on sources, and then turn existing node-level properties into configs that can be set in dbt_project.yml + config blocks. When I say this, I'm especially thinking about source properties like database, loaded_at_field, etc. (I think it would make sense to reserve some properties—description, columns, tests—rather than try to make those work as configs... though there are some valid reasons to want those, too!)
• Support the same config: block-style syntax in dbt_project.yml, as a substitute for the + prefix that everyone finds confusing :)

[jtcohen6]

Update on my comment above, with links to the promised issues:

• The same, but for sources: [CT-201] Reconcile configs + properties for sources #3662
• Symmetry with project file: Support config: in dbt_project.yml, in loco + #3663
• Support config for tests, including meta: looks like we might tackle that as part of this PR!

[jtcohen6]

As discussed, there are three outstanding pieces for this PR:

• Make sure configs are being rendered (using standard .yml file context). Ideally, we'd capture the un-rendered versions in unrendered_config, as we do for config set in dbt_project.yml.
• Merge node.config.meta --> node.meta
• Support a config: dict nested under tests. Support grabbing test configs from config: dict or top-level keys. Raise an exception if the same test config is set in both the config: dict and as a top-level key.

Those are all things we want for feature completeness in v0.21. They don't have to be blockers to merging this specific PR; I'd be happy to open follow-on issue(s), if they'd require nontrivial work and we'd rather get this PR merged now.

[jtcohen6]

Giving this a thumbs-up from an end-user functional perspective. There are likely to be a handful of small things that we want to touch up as people start using this. I'm excited to get it into beta.

🚀 🚀

[brad-meru]

These aren't being captured in dbt Docs. The only way that seems to work is to config in the model.

It would also be great if column tags made it into Docs.