PingSlotInfoReq sent by end-device after receiving McClassBSessionReq - not compliant with LoRaWAN L2 specification

[aelbretonactility]

Problem Description

When a device receives a McClassBSessionReq command from the Remote Multicast
Setup Package, the LBM stack needs to temporarily switch to class B to start the
multicast session, receive fragments, and then revert to its original class when the session ends.

The lorawan_class_b_management service is responsible for enabling Class B. Its
standard flow seems to be:

1. Send PingSlotInfoReq MAC command to the Network Server
2. Wait for PingSlotInfoAns from the Network Server
3. Start beacon search only after PingSlotInfoAns is received
4. Start ping slots only after beacon is locked and PingSlotInfoAns was received

Root Cause

LoRaWAN L2 Specification v1.0.4, Section 12.1 explicitly states:

"This command SHALL be used only to inform the server of the periodicity of a unicast
ping slot. A multicast slot is entirely defined by the application and SHALL NOT use
this command."

As per my understanding, the LBM code is non-compliant with above part of the spec.
After receiving a McClassBSessionReq, steps 1 and 2 should not happen
(unless the device is already in class B with a different ping-slot periodicity),
and the LBM stack should directly start beacon search.