[draft] Add CompositeEMAC and use it to rewrite STM32 Ethernet MAC driver

[multiplemonomials]

Summary of changes

This PR introduces a new framework for writing Ethernet MAC drivers. The existing EMAC interface requires MAC drivers to implement quite a lot of the specifics of memory management, MAC address tracking, and DMA themselves, even though quite a bit of this logic is common to all MAC drivers. This has led to duplicated code, and quite often to half-assed code as well as chip vendors have struggled to conform to the (admittedly not very well defined) EMAC API.

CompositeEMAC should make this a thing of the past. It's a class which implements the EMAC API and delegates its duties to four subclasses:

• A MAC peripheral driver
• A Tx DMA ring driver
• An Rx DMA ring driver
• A PHY driver

The first three of those classes are provided by the chip-specific EMAC driver, while the fourth comes from a library of PHY drivers and is not MCU specific. But this way most of the tough logic can be done in the non-MCU-specific layer, and all that needs to be done on a per-MCU basis is writing the low level MAC driver and low level code to interact with Ethernet descriptors.

Impact of changes

• Ethernet support added for STM32H5
• Significant Ethernet speed improvement for STM32H7: MAC no longer blocks while packets are being sent
• Also, data cache no longer gets disabled when you use Ethernet on STM32H7. Apparently someone just made the driver globally disable the cache to fix a bug...
• Zero-copy Ethernet support for STM32 devices, so small packets can be received with less wasted memory and large packets can be received with no copying
• Generic PHY driver system allows any PHY supported by Mbed to be used with any MCU. Previously the PHY was hardcoded into the EMAC driver, so you had to use that exact model of PHY.

Migration actions required

Documentation

---

Pull request type

[] 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

[] 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

---