Provide user-supplied configs to ParsedNodes before generating alias/schema names

[drewbanin]

Describe the feature

dbt's generate_alias_name and generate_schema_name macros accept a node argument which contains a mostly-complete ParsedNode object. When the generate_schema_name and generate_alias_name macros are called for a node, the tags and configs properties on the ParsedNode are populated with dummy values. Instead, dbt should set the tags and configs properties for the ParsedNode before calling out to the generate_*_name macros.

This is specifically problematic when the generate_alias_name or generate_schema_name macros need to operate on the supplied schema or alias values for a node. In either instance, the user-supplied values for alias and schema will be unavailable in the node's config dictionary.

Who will this benefit?

Users with complex needs around schema / alias generation.

[sfc-gh-aseitz]

+1 to this issue, our use case is when our analytics team is developing new code or modifying existing code, we want them to pass a dev profile along. When the dev profile is passed we want the generate_schema_name macro to operate like:

{% macro generate_schema_name(custom_schema_name, node) -%}
    {%- set default_schema = target.schema -%}
    {%- if target.name == "dev" -%}
        {{ "dev" }}
    {%- elif custom_schema_name is none -%}
        {{ default_schema }}
    {%- else -%}
        {{ custom_schema_name | trim }}
    {%- endif -%}
{%- endmacro %}

and then we want the table names to be aliased in a way that is unique to each user developing such as the db.dev.username_customschemaname_tablename. However, when modifying the schema, you currently lose access to the custom_schema_name variable as it is replaced in the generate_schema_name macro.

The reason is that in testing code changes, users don’t have the ability to write to our production schemas (they have a reduced read-only role) and they can only write to a dev schema, so we figured this might be a nice easy solution to handle users working on the same models at the same time as well, while only re-building parts of the project that are actively being developed on. We also assume table names are not unique and rely on the combination of table name and schema name to define a unique entity (db.salesforce.account vs. db.snowflake.account).