Strict class parameters - proto edition

[freider]

Alternative implementation of #1968 using a simple proto schema instead of cbor2 to encode the parameters.

As long as we are confident the encoded payload will be deterministic, this would be a pretty clean solution IMO as it enforces types harder in the serialization layer than cbor2.

---

Updated PR description from #1968

In "strict" parameter mode, class parameterization change behavior in the following ways:

• serialized_params use the new proto serialization format
• We set class_parameter_format=PARAM_SERIALIZATION_FORMAT_PROTO on the Function definition to indicate the serialization protocol to be used
• We set class_parameter_schema (see proto for format) on the Function definition defining the schema of the parameters of the class (names and types for now)

Reasoning behind class_parameter_schema:

The stored class_parameter_schema is useful/necessary for three main reasons:

• Web endpoint parameterization will need yet another (de)serialization format (not implemented here) - one that goes from query parameters (strings) to a proto native representation of each field. Since query parameters are untyped strings, we'd need some kind of type information to support typed arguments with web endpoint parameterization.
• We can potentially use the schema to hydrate class instances in the client in a way that lets us error out sooner in case of bad arguments to a class constructor (wrong arguments, types etc.). Today these sort of errors don't appear until the launched container starts up and the constructor is actually called (could be considered both bug and feature...)

Feature flag

This new feature is currently gated behind the MODAL_STRICT_PARAMETERS=1 env var and uses the existing class constructor logic but with signature inspection.

When we actually release this to users (when the backend support for web parameterization is live) an idea is to instead activate strict parameters when users use a new kind of dataclass-inspired schema (which has other benefits!), and keep the unstrict behavior of custom constructors, to not break any existing user code.

Note that this is not part of this PR, just an example of how we'd introduce this in a non-breaking way:

@app.cls()
class Foo:
    a: int [= parameter(default=123)]  # 
    b: int = field(init=False)  # non-parameter annotation, stuff that's set in @enter methods etc.

The above syntax would let us use typing.dataclass_transform() to get good editor support for our classes even without explicit constructors 🤓

[freider]

One thing I don't fully understand — what's "strict" about the params here? That they need to have type annotations in the modal class constructor?

Strict as in strictly typed in some sense, and that they (for now) only allow int and str types.

A somewhat unintended (positive) side effect of this mode is that it enforces the right arguments and types are supplied already at the call site, avoiding launch of containers with invalid params. The old "mode" just happily let you instantiate the class with whatever *args, **kwargs you wanted and it wouldn't actually explode until your already newly launched container tried to supply those to the underlying class.

[mwaskom]

A somewhat unintended (positive) side effect of this mode is that it enforces the right arguments and types are supplied already at the call site, avoiding launch of containers with invalid params.

Yeah that's a plus!