refactor: Update materialized column management

[tkaemming]

Problem

• Coordinator nodes currently are not updated using the management tools which can cause problems for high value customers if easily overlooked manual schema synchronization is not performed
• It can be challenging with the existing code to determine what tables are being altered on what hosts and why without understanding implicit expectations baked into the logic (see feat: Support marking materialized columns as disabled and dropping #26068 (comment))
• Slow distributed DDL would be challenging to migrate as written to something that is more resilient to toolbox pod restarts (this doesn't fix the issue, but hopefully nudges in the right direction)
• Some distributed DDL (e.g. DROP INDEX) doesn't appear to actually be deduplicated when using ON CLUSTER and seems to need to be targeted more granularly at individual hosts to ensure efficient execution
• Many similar changes needed to be made anyway to support nullable materialized column types anyway without it being shotgun surgery (feat: Support nullable materialized columns using native types #26448, clickhouse-cluster...column-types in particular)

Changes

• Adds a ClickhouseCluster class that can be used to direct work to either all hosts in the default cluster (including extra hosts, i.e. coordinators - this is the only functional part of this change) or to only one host per shard, with queries executed concurrently across the selected hosts
• Adds utilities for managing concurrent work with less boilerplate (FuturesMap)
• Refactors materialized management commands into chunks based on host responsibility (data node, query node, etc.)

Does this work well for both Cloud and self-hosted?

N/A, ee.* only

How did you test this code?

Covered by existing (but could use more)

[fuziontech]

🚢 it