Rename "constraints_enabled" to "contract"

[gshank]

resolves #6748

Description

After more discussion and considering the scope of this setting, we decided to rename "constraints_enabled" to "contract".

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

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[MichelleArk]

Changes here look good! There is some boilerplate in each adapter implementation that references config.get('constraints_enabled') (dbt-snowflake example), which will need to be updated as well. I can make corresponding issues in the adapter repos 👍

[MichelleArk]

We should close the corresponding adapter issues prior to merging this to prevent breaking tests in adapters, since they inherit from functional tests modified in this PR.

[gshank]

We can't close the adapter issues prior to merging this because the "contract" config wouldn't actually exist in core until after this is merged. The has to merge first, then all of the adapter issues.

[gshank]

Actually, I have a question about this now that I think about it. We're "promoting" the "contract" attribute to the model level. Shouldn't we be accessing it via the model, like "model.contract", and not looking at the config? This is one of those fields where the config is just used to shuttle the value in node level...

[gshank]

So actually the config.get calls should still work in the adapter repos since it doesn't require that the config attribute actually work. But if we did model.contract they might fail.

[sungchun12]

@gshank thanks for evolving contracts by actually having the config called contract. Even that simple visual cue as I tested this out today was so much more intuitive than constraints_enabled.