storage: MySQL's MySqlColumnDesc fails to separate concerns

[sploiselle]

MySQL sources store information about the tables' columns in MySqlColumnDesc:

pub struct MySqlColumnDesc {
    /// The name of the column.
    pub name: String,
    /// The intended data type of this column within Materialize
    /// If this is None, the column is intended to be skipped within Materialize
    pub column_type: Option<ColumnType>,
    /// Optional metadata about the column that may be necessary for decoding
    pub meta: Option<MySqlColumnMeta>,
}

Here is the iimpl of mz_repr::relation::ColumnType:

pub struct ColumnType {
    /// The underlying scalar type (e.g., Int32 or String) of this column.
    pub scalar_type: ScalarType,
    /// Whether this datum can be null.
    #[serde(default = "return_true")]
    pub nullable: bool,
}

MySqlColumnDesc::column_type:

• Is an Option because it is None when users specify IGNORE COLUMNS on this column.
• Is capable of expressing all columns in terms of ScalarType because if the MySQL type is unsupported, we force users to specify TEXT COLUMNS.

This fails to separate concerns––e.g. the MySqlColumnDesc cannot describe the actual upstream table's schema because we apply apply configuration options to it.

If we fully seprated concerns, purification would be able to describe the tables we want to ingest, and processing the TEXT COLUMNS and IGNORE COLUMNS options could occur in planning. With the current design that is impossible.