Defer to prod manifest for partial runs

See also #1612, #1603, and #2465

Describe the feature

In a partial run of dbt (eg. dbt run -m my_model+), all of the parents of my_model and its children must exist for the run to succeed. To this end, we’ve built the @ selector, but another helpful approach would be to defer to relations created by a production run when these parent models are referenced.

When dbt is provided a prod manifest (#2465), it can rewrite references to models based on the information contained in this manifest. Specifically, references to models which are not included in the run (ie. they are not selected, or they are explicitly excluded) should be interpolated as a relation captured in the prod manifest.

This flow will support the following use-cases:

• Slim CI builds that only run new and changed models (without building their parents)
• Local development (don’t run large Snowplow models in dev)
• Orgs with multiple projects where users don’t have permissions to run models in an upstream package

Things to discuss:

• Is this automatic? Or should models be configured as “deferrable” in some way?
• If it needs to be enabled explicitly, is this a model config, a run flag, or something else?
• What happens if a model is not selected and also is not in the prod manifest?
• Does this have any impact on non-models?
  • Seeds
  • Snapshots
  • Tests
• How does this impact the generated manifest for the run? Are the “borrowed” prod models included in the generated manifest? Should they render in the auto-generated documentation?

Additional context

Let’s approach this separately from #2465 but keep this context in mind

Who will this benefit?

• CI
• Local dev
• Large, sprawling, microproject architecture deployments

[beckjake]

I think this is not a “dbt version” situation, but actually a “schema version” situation.

[jtcohen6]

It occurs to me that deferring to artifacts generated by a different dbt version may have surprising effects, in the event that the manifests look quite different. That’s:

• a caveat to document
• all the more reason we need to include dbt versions in all generated artifacts, so we can raise a concrete warning