EMAC memory manager improvements & fixes

[multiplemonomials]

Summary of changes

This PR makes a number of fixes to the EMAC memory manager interface and to the three implementations of the manager (LWIP, Nanostack, and the EMAC test's mem manager). These are required for my upcoming STM32 EMAC MR.

Main changes are:

• Adding a "get_lifetime()" function which can be used to tell what type of buffer a buffer is and how long it will live. This is important so that EMAC drivers can know whether the buffer needs to be copied!
• Making network stack independent options for the Rx buffer pool size and buffer size. This is needed so that the Nanostack memory manager can (pretend to) have a buffer pool that the EMAC can use.
• Adding a callback from the memory manager to the EMAC for when pool buffers are freed. This is important so that the EMAC can reallocate Rx descriptors after new memory becomes free.
• Updating EMACTestMemoryManager to support the concept of an Rx buffer pool with limited size, so that EMAC drivers can be tested correctly
• Changing greentea tests to not select any network stack by default (needed for EMAC test). Now we can compile all the netsocket tests with both LwIP and nanostack!

Impact of changes

Memory manager should have some new functions and be better documented.

Migration actions required

Documentation

---

Pull request type

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

---

Test results

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

---

[multiplemonomials]

See this enum for details on this

[multiplemonomials]

Let's just say I learned this one on the job, the hard way

[multiplemonomials]

This looks like a bug, I'm 99.9% sure. It was causing the include list to be treated as an exclude list! Of course, the include list is still kinda pointless, because it seems to do the same thing as just not putting the buffer on the exclude list, but this makes things slightly less messed up.

[multiplemonomials]

Having individual targets change the TCP settings is causing some build issues (because these LwIP thinks these targets would also need more Rx pool size). I don't know if it's correct or not but either way it's really weird for rando targets to use different TCP settings. If the default TCP settings are wrong for some applications then we should change them everywhere, or provide a guide for users to change them.

[multiplemonomials]

Unfortunately this PR seems to have unearthed some sort of segfault in the LPC1768 LwIP TCP test

It doesn't seem directly related to the test -- looks more like some kind of memory corruption vulnerability. I don't think I have the time to debug this right now but it should def be looked into, esp. if it persists after refactoring the LPC EMAC

[multiplemonomials]

Actually... it appears that LPC1768 ethernet with LwIP is basically broken by this PR. I spent a good hour looking around but I wasn't able to find a smoking gun. I really don't see what exactly changed, but I think the EMAC driver was a bit shaky before (wasn't passing all the EMAC tests), and it has totally broken down now. Nanostack, somehow, does still work, but LwIP and the EMAC test suite seem to be unable to receive packets.

I am planning to totally rewrite the LPC1768 EMAC driver in the near term anyway, so I think I'm going to table this one until I can do that rewrite. It just isn't worth wasting all this effort on a driver whose days are numbered anyway.

On the bright side, I tested this branch with NUCLEO_F429ZI and K64F and all network tests passed there!