fix(frontend): check data type in column id generator

[BugenZhao]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

When generating column ID for existing columns (by name), also check and reject if the data type changes. Otherwise, the persisted data will be incompatible and lead to undefined behavior.

Note that for struct types, the nested fields are encoded with value-encoding (instead of column-aware encoding) under current implementation. As a result, adding new nested fields cannot be supported and should be rejected as well. Close #19736.

This won't be hit for a regular table as we don't provide syntax support for altering the data type for an existing column. However, schema registries may consider this as a compatible change so it can be hit by ALTER TABLE REFRESH SCHEMA.

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• My PR contains critical fixes that are necessary to be merged into the latest release.

Documentation

• My PR needs documentation updates.

Release note

[xiangjinwu]

LGTM

[xiangjinwu]

Yet another example of why Field::sub_fields (and ColumnDesc::field_descs) shall be consolidated into StructType. Currently Field::with_name on struct produces incomplete results - and there is a special Field::with_struct.

No need to fix the usage in this PR as the incomplete results are NEVER used except describe #17128