Unknown type names inside a container are misread instead of rejected #589

Follow-up to the second point of the suggested fix in #571, which #575 leaves aside: validating the elements of a container, so that an unknown type name fails loudly instead of desynchronising the stream.

A type name the parser does not know becomes a Void terminal. At the root, ValidateAST rejects it and the client throws "unsupported column type". Inside a container nothing checks it: the column is created as ColumnNothing, which reads one byte per row, and the rest of the block is misread, with no error naming the type.

In the client itself, on master (fc5d98f):

CreateColumnByType("Int256");         // nullptr, the client reports "unsupported column type: Int256"
CreateColumnByType("Array(Int256)");  // a column typed Array(Void), no error

Against ClickHouse 26.11:

SELECT CAST(1, 'Int256') AS wide     -- UnimplementedError: unsupported column type: Int256
SELECT [CAST(1, 'Int256')] AS wide   -- without compression: one row, no exception, wrong content. With LZ4: some data was not read

Other names a server sends as is and the parser does not know, checked with toTypeName on 26.11: Variant, Dynamic, BFloat16, UInt256, the Interval* types, LineString, MultiPoint, QBit, AggregateFunction. At the root each of them is an error. Inside an Array, what happens depends on the type and the compression: without compression Int256, UInt256, QBit, AggregateFunction and the Interval* types come back as wrong data with no exception, BFloat16, Variant, Dynamic, LineString and MultiPoint fail later with unrelated errors (unimplemented 63, unsupported custom serialization, unimplemented 8176), and with LZ4 every one of them fails with some data was not read. None of these errors names the type. Nothing goes through the same path and only works by accident, one byte per row on both sides, which SELECT [] and SELECT NULL rely on.

#578 handles the neighbouring case, a type the parser accepts but the factory cannot build inside a wrapper, which crashed. This one is about names the parser does not know at all, and the two change different functions.

#590 is a draft for it, stacked on #575 because it needs the Nested node from there. It validates the elements of those six containers, leaves the arguments of every other type alone (JSON settings and typed paths, the function name of SimpleAggregateFunction), and registers Nothing. An unknown name inside a container then makes CreateColumnByType return nullptr, so the client throws the same "unsupported column type" as at the root.

Would you rather have a diagnostic that names the inner type? The draft's tests would then expect it instead of nullptr.