provide AssetExecutionContext class to context

[jamiedemaria]

Summary & Motivation

Introduces the logic to determine which kind of context to provide to which kind of step.

Follows these rules:

@asset + no type annotation -> AssetExecutionContext
@asset + AssetExecutionContext annotation -> AssetExecutionContext
@asset + OpExecutionContext annotation -> OpExecutionContext 
@op + no type annotation -> OpExecutionContext 
@op + AssetExecutionContext annotation -> Error - we need an AssetsDef for AssetExecutionContext init, and op doesn't have one 
@op + OpExecutionContext -> OpExecutionContext 

The ops that make up graph backed assets is where is gets funky. This is what would happen in the current implementation:

@graph_asset @op + no type annotation -> OpExecutionContext
@graph_asset @op + AssetExecutionContext -> AssetExecutionContext 
@graph_asset @op + OpExecutionContext -> OpExecutionContext

The reasoning behind @graph_asset @op + no type annotation -> OpExecutionContext is best explained with an example:
Imagine you have an op that is used in both a job and a graph-backed asset

@op 
def my_fun_op(context):
   context.describe_op # this function is on the OpExecutionContext, but not on the AssetExecutionContext

@job 
def my_fun_job():
    my_fun_op()

@graph_asset 
def my_fun_asset():
    my_fun_op()

When executing my_fun_job, my_fun_op will receive an OpExecutionContext and run as expected. When materializing my_fun_asset, my_fun_op will receive an AssetExecutionContext. It will fire a deprecation warning, but still call describe_op on the internally held op_execution_context. When we deprecate the __get_attr__ behavior here, my_fun_op will instead error.

How I Tested These Changes

[jamiedemaria]

Current dependencies on/for this PR:

• master
  • PR interface for ExtContext and AssetExecutionContext #16480
    • PR Make AssetExecutionContext a subclass of OpExecutionContext #16596
      • PR partition methods on AssetExecutionContext #16625
      • PR provide AssetExecutionContext class to context #16493 👈
        • PR update build_op_context to build_asset_context where relevant #16673
          • PR support direct invocation with AssetExecutionContext #16635
            • PR test AssetExecutionContext subclass deprecations #16598
    • PR OpExecutionContext metaclass #16486
      • PR Simplified AssetExecutionContext #16487

This comment was auto-generated by Graphite.

[jamiedemaria]

in combination with is_sda_step this will tell us if an op is in a graph backed asset.

[jamiedemaria]

Edge case to consider:

@op(config_schema={"foo": int})
    def one(context):
        assert context.op_config["foo"] == 1

asset_one = AssetsDefinition.from_op(one)

the op gets an AssetExecutionConext - need to decide if that's what we want

[jamiedemaria]

TODO - i'd like to move this check to one we can catch at definition time, but i'm not sure if we can since with just this

@op 
def my_op(context: AssetExecutionContext)

we don't know if the op will be used in a graph backed asset (meaning this annotation is fine) or in an op job (meaning this annotation is not fine)

[alangenfeld]

the change discussed in the summary got landed in another PR right?

[jamiedemaria]

closed in favor of #16759