Prevents Topology Infinite Loop

[matt001k]

What changed?

On a timeout event in the topology task, if on the root node, prevent changing the cursor.

How does it make Bristlemouth better?

If running a topology request on the root node, this prevents an infinite loop from occurring by ensuring that the topology cursor cannot be changed if the neighbor request retry limit has been hit.

Where should reviewers focus?

This prevents a node from hanging in the topology task and tripping the watchdog, but this does not prevent handling link up/down events from a non-ADIN device, such as the UART for bm_sbc. Because of this behavior, when a UART device is no longer available, the topology task takes about 3 seconds to finish after waiting for all of the retries to occur (because the Bristlemouth stack still thinks the UART port is up).
We need to think of a way to trigger link_change in l2.c for the UART device, but that will have to occur when implementing the composite device.

Checklist

• Add or update unit tests for changed code
• Ensure all submodules up to date. If this PR relies on changes in submodules, merge those PRs first, then point this PR at/after the merge commit
• Ensure code is formatted correctly with clang-format. If there are large formatting changes, they should happen in a separate whitespace-only commit on this PR after all approvals.

[victorsowa12]

Talked IRL with Matt.

He has found another area that fixes the condition that causes the infinite loop be switching a == check to a <= check.

We also discussed potentially removing the network_topology_move calls from here and having this timeout just send a check node event. This will require some more testing.