Convert AssetSelection subclasses from NamedTuples to Pydantic

[maximearmstrong]

Summary & Motivation

This PR updates AssetSelection and its subclasses to inherit from pydantic.BaseModel instead of NamedTuple. NamedTuple._replace() was replaced by AssetSelection.replace(), a wrapper for copy (pydantic v1) and model_copy (pydantic v2)

After several attempts, to make this work

• the super class AssetSelection must inherit from pydantic.BaseModel
• the super class and subclasses must have the config frozen=True, which allows all of them to be immutable, like NamedTuple.

Because of that, this PR udpates:

• all classes in asset_selection.py to reflect the changes.
• the class DbtManifestAssetSelection in dagster-dbt, which inherits from AssetSelection. It is now immutable.
• the code using the classes - when inheriting from pydantic.BaseModel, instantiating new objects require keyword-only arguments except if __init__() is redefined for the class, so the code was updated to use the keywords.
• the tests to reflect the changes.

How I Tested These Changes

BK

[sryza]

hallelujah!

[alangenfeld]

a relatively light weight back-compat test would be to get a serialized string for one/some of these in master and check it in directly to a test ensuring it loads successfully. This can de done with serialize_value and deserialize_value from dagster._serdes

edit: There are general tests for NamedTuple -> dataclass in the serdes library, so adding a specific test here isn't necessary, just some extra validation and maybe a good learning exercise.

[alangenfeld]

could consider using pydantic dataclass if we want these to be run time type checked

https://docs.pydantic.dev/latest/concepts/dataclasses/

but since it appears the original NamedTuple variants did not have a custom __new__ with checks that would be new additional behavior

[maximearmstrong]

I thought it was a good idea and wanted to do it, but I seems pydantic doesn't support replace, so I think for this use case we can keep dataclasses which does.

[sryza]

Would model_copy work? pydantic/pydantic#3352

[alangenfeld]

We support both pydantic 1 & 2 and those comments make it seem like model_copy is 2 only, something to double check

[maximearmstrong]

Oh, interesting. That would most likely work. I will implement it before merging.

[alangenfeld]

looks like copy -> model_copy was a name change in 1 -> 2
https://docs.pydantic.dev/latest/migration/#changes-to-pydanticbasemodel
so I think we would need to handle that

[sryza]

we could write a wrapper

[maximearmstrong]

After a few attempts to properly handle inheritance and frozen classes, the code and PR description are updated. @alangenfeld @sryza, lmk what you think!

[alangenfeld]

maybe worth adding a test that demonstrates the new runtime type checking that this adds

[alangenfeld]

could consider having this be **kwargs if we wanted to not have to change the replace callsite args

[maximearmstrong]

Done in 37aea77

[maximearmstrong]

maybe worth adding a test that demonstrates the new runtime type checking that this adds

@alangenfeld Good call, done in b9db7f0