Fix spurious link up/down when AP IP address range change

[cydriftcloud]

Description

Fixed additional link notification in whd_wifi_link_state_change_handler by checking additional conditions during the link state transition.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

Release Notes

[ciarmcom]

@cydriftcloud, thank you for your changes.
@maclobdell @ARMmbed/mbed-os-ipcore @ARMmbed/mbed-os-maintainers please review.

[kjbracey]

Seems possibly plausible, but just to be clear - the Mbed OS network status events are intended to indicate things that applications may need to be aware of, like the device's assigned IP addresses changing. If we got a new DHCP address, for example, I'd expect another "GLOBAL_UP" event (without a "DOWN" first).

Repeated "ups" can be used to signal "something may have changed", giving the application the option to take action.

Although that doesn't seem to have reached documentation in https://os.mbed.com/docs/mbed-os/v5.14/apis/network-status.html

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

[cydriftcloud]

Seems possibly plausible, but just to be clear - the Mbed OS network status events are intended to indicate things that applications may need to be aware of, like the device's assigned IP addresses changing. If we got a new DHCP address, for example, I'd expect another "GLOBAL_UP" event (without a "DOWN" first).

This fix deals with how that "GLOBAL_UP" event is generated based on the underlying whd event. During the deauth and re-join process, the underlying whd will go through multiple states. We do not intend to generate multiple "GLOBAL_UP" events as this should be considered as a single disconnect->connect event.

[kjbracey]

Okay, as long as you're still generating at least one event when the IP address changes, that's fine.