[1.3] Remove encoding of network technology specific attributes of the Network commissiong driver when this technology isn't use by the device

[jmartinez-silabs]

Reproduction steps

Read one of the attribute that doesn't match the device network technology type.

./chip-tool networkcommissioning read supported-wi-fi-bands <node_id> 0
or

./chip-tool networkcommissioning read supported-thread-features <node_id> 0
./chip-tool networkcommissioning read thread-capabilities <node_id> 0

It returns a valid value of 0 in the expected type.

Bug prevalence

always

GitHub hash of the SDK that was being used

Merge of #31328

Platform

core

Platform Version(s)

No response

Type

Common Cluster Logic, Spec Compliance Issue

Anything else?

The pr #31328
enables both Wifi and Thread related attributes of the network commissioning cluster on the All-cluster-ap, regardless of what network technology the device supports.
This is done so CSG can validate those technology-dependent mandatory attributes on a reference app.

Because the test harness evaluates the attribute list of the device in the wild card read test, We currently have to encode a valid TLV value for those attributes even if the device running the all-cluster-app doesn't support one network technology or the other.

Some work needs to be done to alter the attribute list in this case where a common zap configuration is used for a reference app resulting in a non-spec compliant configuration. Once a solution for this problem is implemented, we must remove the unconditional encoding of a value for the supported-wi-fi-bands, supported-thread-features and thread-capabilities attributes

This is solely due to the reference app running against the test harness and it is understood that real-world products shall not use said non-spec compliant zap configuration.