Networking subsystem should not (re)define C library types, macros or functions

[aescolar]

Problem Description

Today the networking subsystem defines quite a few types/structures & macros & functions which are in general expected to be defined by the C library (POSIX extensions).
Mainly https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/net/net_ip.h
Those are then used by the networking subsystem itself, and other subsystems, drivers and modules.

Defining these in Zephyr "core" components, means that if the C library, or another component (for ex. the POSIX API compatibility layer) provides or tries to provide any of these we have conflicts or complex interrelationships in which we try to work around each other.
But in general there is no safe way to handle a setup like this, as any attempt to try to define these in the networking subsytem needs to assume that either the other do not define it, or, that the definitions are exactly the same, or, that there is a way to detect and not define it if the other side has defined it, and/or, that we will include one header before the other, or the like.

In general it would be preferred if the networking subsystem would not define any of these types, but would instead define and use its own Zephyr native types, macros and functions. And that, when necessary and desirable, the POSIX compatibility API would then define the POSIX types as a translation into these native types.

Proposed Change

(This is just a rough proposal)
In net_ip.h all structures/types and macros which today have the same name as C library (or POSIX) standard ones would be renamed with a prefix.
A new header would be created translating from the "old"/standard name to the new prefixed name.
Transitionally that new header would be included from the old one.
All current users would transition to use the new prefixed name.
After deprecation has been completed, the POSIX compatibility layer can then (if desired) include that translation header or in another way provide that translation. That is, at that point, Zephyr "core" components would not be using the old names anymore.