ngram bloomfilter index based on IPv6 type breaks in v23.3

[bharatnc]

Describe the unexpected behaviour
We are trying to upgrade from v22.3-lts to v23.3-lts. This is when we noticed that v23.3 wasn't happy with ngram bloom filter indices we had defined on IPv6 type.

How to reproduce

• v22.3: https://fiddle.clickhouse.com/623b1437-2ad7-4803-b33f-8793d3e9a87e
• v23.3: https://fiddle.clickhouse.com/9eaef7e1-c306-45d2-bffa-1cd359337a87

• Which ClickHouse server version to use: v23.3-lts
• Queries to run that lead to unexpected result

DROP TABLE IF EXISTS table1;
CREATE TABLE table1 (foo IPv6, INDEX fooIndex foo TYPE ngrambf_v1(8,512,3,0) GRANULARITY 1) ENGINE = MergeTree() ORDER BY foo;
DETACH table table1;
ATTACH TABLE table1;
DROP TABLE table1;

Expected behavior
I would ideally expect this to behave the same as is behaves in v22.3-lts.

Error message and/or stacktrace

Received exception from server (version 23.3.8):
Code: 80. DB::Exception: Received from localhost:9000. DB::Exception: Ngram and token bloom filter indexes can only be used with column types `String`, `FixedString`, `LowCardinality(String)`, `LowCardinality(FixedString)`, `Array(String)` or `Array(FixedString)`. (INCORRECT_QUERY)
(query: CREATE TABLE table1 (foo IPv6, INDEX fooIndex foo TYPE ngrambf_v1(8,512,3,0) GRANULARITY 1) ENGINE = MergeTree() ORDER BY foo;)

Additional context

I think the issue here is that IPv6 used to be based on FixedString(16) if I recall correctly. But since v23.3, it looks like it's now based on IPv6 native type: https://github.com/ClickHouse/ClickHouse/pull/43221 (which seems to have an underlying type of UInt128).

What could be the possible fix/approach here for the upgrade since this change looks backwards incompatible.

Thank you in advance for taking a look at my issue.

[bharatnc]

cc: @yakov-olkhovskiy