[SL-UP] Updated GetMotionLockStatus Logic

[Arghya Dutta (silabs-ArghyaD)]

Summary

This PR is only created for internal review
The current logic for GetMotionLockStatus first checks the kOperational in ConfigStatus first and then checks the Mode. Following the Matter Specs -

While in maintenance mode, all commands (e.g: UpOrOpen, DownOrClose, GoTos) or local inputs that can result in movement, must be ignored and respond with a BUSY status. Additionally, the Operational bit of the ConfigStatus attribute should be set to its not operational value.

We're making sure that the ModeSet internally calls the ConfigStatusSet

    if (oldMode != newMode)
        Attributes::Mode::Set(endpoint, newMode);

    if (oldStatus != newStatus)
        ConfigStatusSet(endpoint, newStatus);

So it's not necessary to check the kOperational in ConfigStatus first in GetMotionLockStatus.

Related issues

N/A

Testing

• Tested locally with CSA test scripts. The test cases were passing.

Readability checklist

The checklist below will help the reviewer finish PR review in time and keep the
code readable:

• PR title is
  descriptive
• Apply the
  “When in Rome…”
  rule (coding style)
• PR size is short
• Try to avoid "squashing" and "force-update" in commit history
• CI time didn't increase

See: Pull Request Guidelines

[Rohan Sahay (rosahay-silabs)]

LGTM but SL-UP to main should be on CSA

[Arghya Dutta (silabs-ArghyaD)]

LGTM but SL-UP to main should be on CSA

This PR is just for internal review. I'll raise a separate CSA PR for this.