matter: re-enable Valve Configuration and Control cluster

[lboue]

Description of Change

configs/defconfig.common has a block explicitly disabling ~50 rarely-used Matter clusters to save flash ("Exclude Matter Clusters for saving memory space"), including:

CONFIG_SUPPORT_VALVE_CONFIGURATION_AND_CONTROL_CLUSTER=n

This means the CHIP src/app/clusters/valve-configuration-and-control-server/ directory never gets compiled into the CHIP static library shipped in esp32-arduino-libs (verified: esp_matter's own Kconfig-driven cluster_dir.cmake gates that same directory on this exact symbol, for both the ember-style implementation in esp_matter 1.5.x and the newer cluster-class implementation in 1.6.0+ - this isn't specific to either architecture generation).

esp_matter's own wrapper code (esp_matter_cluster.cpp, esp_matter_command.cpp, esp_matter_delegate_callbacks.cpp) calls into that cluster's CHIP functions/ember callbacks unconditionally, without guarding those call sites behind the same Kconfig symbol. So as long as it's disabled here, anyone trying to actually use esp_matter::cluster::valve_configuration_and_control / esp_matter::endpoint::water_valve hits undefined references at link time (not a compile error, so it's easy to miss until you actually try to build something that uses it).

Found this while working on espressif/arduino-esp32#12853 (a new MatterWaterValve endpoint for the Water Valve device type). Full trace and analysis in espressif/esp32-arduino-lib-builder#390.

This PR drops the line, falling back to esp_matter's own Kconfig default (y) for this cluster, so it gets included again.

Tradeoff / open question for maintainers

This is a deliberate flash-size exclusion list, not a bug, so re-enabling this cluster does grow the CHIP static lib for every board/target that pulls in Matter support - not just ones that end up using Water Valve. I don't have a way to measure the exact size delta from this environment. If that's a concern, alternatives I'd be glad to implement instead:

• Scope this to specific targets only (e.g. boards commonly paired with Water Valve use cases).
• Leave it disabled here and instead guard esp_matter's own call sites behind #ifdef CONFIG_SUPPORT_VALVE_CONFIGURATION_AND_CONTROL_CLUSTER (filed as an option in esp-matter#1830) so disabling it fails at compile time with a clear message instead of a link error - though that alone wouldn't make Water Valve usable through this toolchain, just fail more clearly.

Test Environment

• Not built/tested in this environment - I don't have the resources to run a full esp32-arduino-lib-builder build (this compiles the entire toolchain, not a single sketch). This is a one-line, low-risk change that mirrors the existing pattern for every other cluster in this list, but it should be validated by a real build of esp32-arduino-libs and a link test against MatterWaterValve before merge.

[me-no-dev]

@SuGlider PTAL

[SuGlider]

@SuGlider PTAL

The PR is fine. It enables the necessary cluster in order to add the Valve endpoint to the ESP32 Matter Library.
All not used clusters were disabled in order to save some SRAM bytes with lower RAM SoC, such as C3 and C5.

[lboue]

Did you know that some jobs are failing?

[lboue]

Hi @me-no-dev @SuGlider,

Thanks for merging #391 quickly.

Since arduino-esp32 consumes the precompiled esp32-arduino-libs binaries rather than building CHIP from source, I believe #12853 (MatterWaterValve) can't fully link against esp_matter::endpoint::water_valve until a new esp32-arduino-libs release/tag is published with this change included.

Is there a scheduled release cadence for esp32-arduino-libs, or a way to request an on-demand rebuild/publish after a fix like this lands? Just want to know what to watch for before I can get a full link test done on #12853.

Thanks!

[SuGlider]

we are planing to release a new Arduino Core by next week. It shall contain this and other Matter features.