Workflow [PR], commit [fc773bf]

I do not think this test 00757_enum_defaults_const_analyzer is actually correct:
(Introduced in #59986)

Firstly, for Nullable data type default value is Null:

And the value in output of the test is not null only because original column (ColumnConst in our case) is propagated all the way to output, and the result we see in this test is the default value of the ColumnConst itself (Default value == column value in this case), not its underlying type. So, it is a default value for ColumnConst in this particular case, not for the Enum default value or even a string default value.

It used to behave differently before analyzer was introduced, which is correct IMO: https://fiddle.clickhouse.com/a3af412c-582d-42e5-baf1-8f9a7e46b4aa

This is also counter-intuitive when comparing it to what docs say: key columns containing default values (zeros or empty lines), which is very hard to expect to be the default value of ColumnConst, not its underlying type default value. If we change the ColumnConst, the TOTALS will also change: https://fiddle.clickhouse.com/6a370979-6f6f-49d7-ac67-e17b31fedb21

@azat what do you think?

https://fiddle.clickhouse.com/654a66cb-ff0a-44ef-9a2e-3925769c4a23

@yakov-olkhovskiy the CI is green, PR ready for review

The idea behind this PR is described in the comment above.

In a couple of words it is like this:
The original column (which is ColumnConst) is kind of duplicated to avoid losing its original type unexpectedly. In most cases this is a good idea, but not in this particular case: it is OK if column loses its constness when processing aggregation. Otherwise, the result would be incorrect. So, for this case we add an option not to preserve the original column when processing aggregation.