ESP8266 "busy s..." fix (ONME-4352)

[AnttiKauppila]

Description (required)

ESP8266 modem might return "busy s..." when application tries to send. That means modem is still busy sending some previous data. ESP specification is not 100% accurate how this scenario should be treated, but we found some information that we should wait until we receive "SEND OK" from modem and then try again. This PR tries to do that.
This is not easy to reproduce so we will need approval from different stakeholders before we can merge this in. -> "do not merge" label added for now.

Summary of change (What the change is for and why)

Documentation (Details of any document updates required)

---

Pull request type (required)

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results (required)

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR
[X] Manual/Custom testing needed

---

Reviewers (optional)

@ARMmbed/mbed-os-ipcore @teetak01 @anttiylitokola

---

Release Notes (required for feature/major PRs)

Summary of changes

Fix for https://jira.arm.com/browse/ONME-4352

Impact of changes

Migration actions required

[ciarmcom]

@AnttiKauppila, thank you for your changes.
@anttiylitokola @teetak01 @ARMmbed/mbed-os-ipcore @ARMmbed/mbed-os-maintainers please review.

[SeppoTakalo]

This requires now manual verification, but if all assumptions are correct, it might be the right solution.

[teetak01]

Verified the fix with ~200 functional test-case repeats.

[AnttiKauppila]

This seems to work better now. Seppo still wanted some more logs, but that can be done as a separate task. Let's try to get this in.

[0xc0170]

@AnttiKauppila Please add this to the bugfix commit message:

ESP8266 modem might return "busy s..." when application tries to send. That means modem is still busy sending some previous data. ESP specification is not 100% accurate how this scenario should be treated, but we found some information that we should wait until we receive "SEND OK" from modem and then try again. This PR tries to do that.
This is not easy to reproduce so we will need approval from different stakeholders before we can merge this in. -> "do not merge" label added for now.

also oob handling added for OK in busy scenario commits remove some unittests - not clear why?

I'll fix pr merge in the meantime

[0xc0170]

I started CI, but still would like to have above ^^

[0xc0170]

As soon as the oob handling added for OK in busy scenario commit is extended, this is ready for CI

[AnttiKauppila]

Made a new commit enabling some more logging so that we see the full picture what is happening in this scenario. When tests have been run, I will need to remove the logging before we proceed with merging

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

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

[adbridge]

@AnttiKauppila what extra changes have come in after your forced push? Looks like this should need a re-review ?

[adbridge]

I will however start the ci in the meantime

[mbed-ci]

Test run: SUCCESS

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

[AnttiKauppila]

Made a new commit enabling some more logging so that we see the full picture what is happening in this scenario. When tests have been run, I will need to remove the logging before we proceed with merging

@adbridge This logging was removed because we don't want to have it in master +rebase with master of course