Implement socket_bind and socket_accept

[janjongboom]

@geky @sarahmarshy

Work in progress... Tested with https://developer.mbed.org/teams/ST/code/mbed-os-tcp-server-example/

I'd like some feedback on the approach (working around the ATParser library quirks) before cleaning it up.

[janjongboom]

What I basically need is a function that I can call every X ms. which says: "Do you have any data in your buffers that has CONNECT or CLOSE in them". Then, as long as the RxIrq is attached properly we shouldn't need this weird pinging (it's also not thread-safe).

[janjongboom]

A problem with the ATParser library is that it only processes information when you ask it to, which is great for simple request/response patterns, but not for real OOB data like sockets connecting. I implemented a second buffer which handles CONNECT and CLOSED commands. This way we cannot miss any commands. Also, added some logic for sockets disconnecting, which currently causes the library to hang indefinitely on the recv() call. This PR also needs ARMmbed/ATParser#10.

[janjongboom]

Ping @geky @sarahmarshy

[janjongboom]

Ping again @geky @sarahmarshy

[SeppoTakalo]

Outdated, closing...

[janjongboom]

@SeppoTakalo Since when is outdated a reason to close issues without discussion?!

I want to have a discussion about the approach first before rebasing this.

/cc (again!) @sarahmarshy @geky

[SeppoTakalo]

For issues, its not valid but for pull requests it is a valid reason.

Ownership of this driver is now transferred to my team and I only checked that this PR seems to be abandoned for a while, therefore I closed.

ESP driver have gone lot of rework since this have been published so I cannot know whether this is valid anymore. For improvements, I would like to first see the failing testcase or liked issue.

From testcases, I can see that this driver fails on accept() and bind() tests so this PR might be valid, but it needs to be updated before we can review it.

[janjongboom]

@SeppoTakalo Yes, it's abandoned because no-one has given a second to look at the PR. What am I supposed to do in that case? I've been trying to get someone to look at the way this is implemented for the last 5 months.

accept() and bind() are not implemented in the ESP8266 driver, and this is one way of implementing it. It would be good if someone could evaluate the way that I implemented this, and see if it's a good approach. If so, it can be rebased on master.

[geky]

The code shouldn't have divereged too much. Not just this pr, but all features going into ESP8266Interface have been frozen for a while (sorry @janjongboom!).

[SeppoTakalo]

This is now ticket ONME-3341 and we can take ownership of the work within our sprints.