Identify a peer device as a sleepy device

[pan-apple]

Problem

Sleepy devices may require special handling of MRP parameters, attribute read/write and commands. The current specifications do not have clear mechanism via which a device can advertise itself as a sleepy device. There are a few cluster definitions and DNSSD advertisements that can be used to build a heuristics to treat a peer device as sleepy.

https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/PowerSourceCluster.adoc#14-features

https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/PowerSourceConfigurationCluster.adoc

and, CRA/CRI parameters in DNSSD advertisements.

Need an algorithm design and implementation that can identify a device as sleepy device.

The information about CRA and CRI can be stored in src/lib/dnssd/DnssdCache.h. An API can be written on top of these parameters to determine if the device is sleepy or not.

[SkipAshton]

I believe the only mechanism we have for the 1.0 release is for devices to define sleepy devices as those that are not using default values for CRA/CRI in either their DNS or PASE/CASE session establishment.
Those devices should be marked as sleepy and messaging queued and managed as per the initial PR done in #11471 by @kkasperczyk-no

[turon]

PR to add IsSleepy() that returns true if MRP parameters > default planned to be posted later today by Infineon.

[Damian-Nordic]

What exactly is going to change on the controller side if it determines that a peer device is SED?

• The MRP engine doesn't really need to know if the peer device is SED or just a normal device accessible through several network switches (which results in longer latency).
• If a more complex mechanism is needed, such as polling the controller for new messages, I think we need a more reliable way of determining what behavior is desired by the device as many Thread SEDs will most likely prefer relying on Thread router buffering than the controller polling mechanism.

[pan-apple]

Few optimizations could use this flag

1. Queue up messages locally targeted for a peer sleepy device. As, matter SDK allows for one message at a time for reliable communication.
2. Cache attributes for read/write operations targeting a sleepy device.

These optimizations are not part of the current TE7.5 plan. So the flag may not be used in the code right away.

[pan-apple]

Fixed by #12447