Result data type aggregation is done when we need to mix two or more expressions of different data types to return a value.
Examples:

SELECT a FROM t1 UNION SELECT b FROM t1;

SELECT CASE WHEN cond THEN a ELSE b END FROM t1;

SELECT COALESCE(a,b) FROM t1;

SELECT IFNULL(a,b) FROM t1;

SELECT IF(cond,a,b) FROM t1;

Data type aggregation for comparison (e.g. operators =, <,>, functions LEAST,GREATEST) is out of scope of this task and will be done separately.

Currently result data type aggregation is done with help of the array field_types_merge_rules. When adding a new data type, the developer would normally extend this array. The code assumes that any two data types can be mixed to each other.

Mixing of any arbitrary data types (like INT, DOUBLE, VARCHAR) was OK for the general purpose data types. But as we'll be adding special purpose data types like INET6, some mixtures will be meaningless. For example, mixing INET6 with TIME does not seem to have any sense.

New data type implementations should be able to decide:
1. to which other data types it can be mixed with, or cannot be mixed with (with a possibility to raise an error if mixing is not possible)
2. what is the result data type if mixing is possible

Under terms of this tasks we'll implement a special registry which will contain the above information. Later, when we implement data type plugins, the server will add mixing rules to this registry when loading a new data type plugin.

The patch for this task will not change behavior for the existing data types, and they will keep using field_types_merge_rules, as this implementation is very efficient.

The only exception is GEOMETRY, which is not a general purpose data type. We will change GEOMETRY to use the new data type aggregation registry instead of the field_types_merge_rules-based code. Meaningless mixtures of GEOMETRY with other data types will be disallowed.