doc: net: fix Sphinx C domain roles usage

use the proper types/syntax for referencing C elements from Networking
docs

Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>

doc/connectivity/networking/api/net_l2.rst

@@ -38,7 +38,7 @@ See also :ref:`network stack architecture <network_stack_architecture>` for
 more details. The generic L2 API has these functions:
 
 - ``recv()``: All device drivers, once they receive a packet which they put
-  into a :c:type:`net_pkt`, will push this buffer to the network
+  into a :c:struct:`net_pkt`, will push this buffer to the network
   stack via :c:func:`net_recv_data`. At this point, the network
   stack does not know what to do with it. Instead, it passes the
   buffer along to the L2 stack's ``recv()`` function for handling.
@@ -89,7 +89,7 @@ Ethernet device driver
 
 On reception, it is up to the device driver to fill-in the network packet with
 as many data buffers as required. The network packet itself is a
-:c:type:`net_pkt` and should be allocated through
+:c:struct:`net_pkt` and should be allocated through
 :c:func:`net_pkt_rx_alloc_with_buffer`. Then all data buffers will be
 automatically allocated and filled by :c:func:`net_pkt_write`.
 
@@ -139,7 +139,7 @@ here as well. There are two specific differences however:
   of :c:func:`ieee802154_send` takes care of IEEE 802.15.4 standard packet
   preparation procedures, splitting the packet into possibly compressed,
   encrypted and otherwise pre-processed fragment buffers, sending one buffer
-  at a time through :c:type:`ieee802154_radio_api` tx function and unreferencing
+  at a time through :c:struct:`ieee802154_radio_api` tx function and unreferencing
   the network packet only when the transmission as a whole was either successful
   or failed.
 
@@ -148,7 +148,7 @@ Interaction between IEEE 802.15.4 radio device drivers and L2 is bidirectional:
 - L2 -> L1: Methods as :c:func:`ieee802154_send` and several IEEE 802.15.4 net
   management calls will call into the driver, e.g. to send a packet over the
   radio link or re-configure the driver at runtime. These incoming calls will
-  all be handled by the methods in the :c:type:`ieee802154_radio_api`.
+  all be handled by the methods in the :c:struct:`ieee802154_radio_api`.
 
 - L1 -> L2: There are several situations in which the driver needs to initiate
   calls into the L2/MAC layer. Zephyr's IEEE 802.15.4 L1 -> L2 adaptation API
@@ -161,7 +161,7 @@ Interaction between IEEE 802.15.4 radio device drivers and L2 is bidirectional:
   as well as other hardware-related configuration to L2. Similarly, drivers may
   indicate performance or timing critical radio events to L2 that require close
   integration with the hardware (e.g. :c:func:`ieee802154_handle_ack`). Calls
-  from L1 into L2 are not implemented as methods in :c:type:`ieee802154_radio_api`
+  from L1 into L2 are not implemented as methods in :c:struct:`ieee802154_radio_api`
   but are standalone functions declared and documented as such in
   :zephyr_file:`include/zephyr/net/ieee802154_radio.h`. The API documentation will
   clearly state which functions must be implemented by all L2 stacks as part

doc/connectivity/networking/conn_mgr/main.rst

@@ -311,7 +311,7 @@ If this happens, the :ref:`timeout event<conn_mgr_control_events_timeout>` is ra
 Connection Persistence
 ----------------------
 
-Each iface also has a connection persistence setting that you can enable or disable by setting the :c:enumerator:`~conn_mgr_if_flag.CONN_MGR_IF_PERSISTENT` flag with :c:func:`conn_mgr_binding_set_flag`.
+Each iface also has a connection persistence setting that you can enable or disable by setting the :c:enumerator:`CONN_MGR_IF_PERSISTENT` flag with :c:func:`conn_mgr_binding_set_flag`.
 
 This setting specifies how the iface should handle unintentional connection loss.
 
@@ -416,7 +416,7 @@ There are a few actions related to connectivity that are (by default at least) p
 
    In Zephyr, ifaces are automatically taken admin-up (see :ref:`net_if_interface_state_management` for details on iface states) during initialization.
 
-   Applications can disable this behavior by setting the :c:enumerator:`~net_if_flag.NET_IF_NO_AUTO_START` interface flag with :c:func:`net_if_flag_set`.
+   Applications can disable this behavior by setting the :c:enumerator:`NET_IF_NO_AUTO_START` interface flag with :c:func:`net_if_flag_set`.
 
 .. _conn_mgr_control_automations_auto_connect:
 
@@ -424,7 +424,7 @@ There are a few actions related to connectivity that are (by default at least) p
 
    By default, Connection Manager will automatically connect any :ref:`bound <conn_mgr_impl_binding>` iface that becomes admin-up.
 
-   Applications can disable this by setting the :c:enumerator:`~conn_mgr_if_flag.CONN_MGR_IF_NO_AUTO_CONNECT` connectivity flag with :c:func:`conn_mgr_if_set_flag`.
+   Applications can disable this by setting the :c:enumerator:`CONN_MGR_IF_NO_AUTO_CONNECT` connectivity flag with :c:func:`conn_mgr_if_set_flag`.
 
 .. _conn_mgr_control_automations_auto_down:
 
@@ -432,7 +432,7 @@ There are a few actions related to connectivity that are (by default at least) p
 
    By default, Connection Manager will automatically take any bound iface admin-down if it has given up on associating.
 
-   Applications can disable this for all ifaces by disabling the :kconfig:option:`CONFIG_NET_CONNECTION_MANAGER_AUTO_IF_DOWN` Kconfig option, or for individual ifaces by setting the :c:enumerator:`~conn_mgr_if_flag.CONN_MGR_IF_NO_AUTO_DOWN` connectivity flag with :c:func:`conn_mgr_if_set_flag`.
+   Applications can disable this for all ifaces by disabling the :kconfig:option:`CONFIG_NET_CONNECTION_MANAGER_AUTO_IF_DOWN` Kconfig option, or for individual ifaces by setting the :c:enumerator:`CONN_MGR_IF_NO_AUTO_DOWN` connectivity flag with :c:func:`conn_mgr_if_set_flag`.
 
 .. _conn_mgr_control_api: