doc/developer: fix C struct references

Sphinx wants `c:struct:: foo` rather than `c:type:: struct foo`.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

doc/developer/link-state.rst

@@ -53,15 +53,15 @@ Data structures
 
 3 types of Link State structure have been defined:
 
-.. c:type:: struct ls_node
+.. c:struct:: ls_node
 
    that groups all information related to a node
 
-.. c:type:: struct ls_attributes
+.. c:struct:: ls_attributes
 
    that groups all information related to a link
 
-.. c:type:: struct ls_prefix
+.. c:struct:: ls_prefix
 
    that groups all information related to a prefix
 
@@ -73,7 +73,7 @@ identifier which advertises the Link State and a bit mask as flags to
 indicates which parameters are valid i.e. for which the value is valid and
 corresponds to a Link State information conveyed by the routing protocol.
 
-.. c:type:: struct ls_node_id
+.. c:struct:: ls_node_id
 
    defines the Node identifier as router ID IPv4 address plus the area ID for
    OSPF or the ISO System ID plus the IS-IS level for IS-IS.
@@ -159,10 +159,11 @@ A unique Key is used to identify both Vertices and Edges within the Graph.
 
 4 data structures have been defined to implement the Graph model:
 
-.. c:type:: struct ls_vertex
-.. c:type:: struct ls_edge
-.. c:type:: struct ls_prefix
-.. c:type:: struct ls_ted
+.. c:struct:: ls_vertex
+.. c:struct:: ls_edge
+.. c:struct:: ls_ted
+
+ - :c:struct:`ls_prefix`
 
 TED stores Vertex, Edge and Subnet elements with a RB Tree structure.
 The Vertex key corresponds to the Router ID for OSPF and ISO System ID for
@@ -412,7 +413,7 @@ Data Structures
 The Link State Message is defined to convey Link State parameters from
 the routing protocol (OSPF or IS-IS) to other daemons e.g. BGP.
 
-.. c:type:: struct ls_message
+.. c:struct:: ls_message
 
 The structure is composed of:
 

doc/developer/logging.rst

@@ -489,7 +489,7 @@ calls to :c:func:`zlog_tls_buffer_flush()` in appropriate places:
    buffer.  This function is safe to call regardless of the per-thread log
    buffer being set up / in use or not.
 
-When working with threads that do not use the :c:type:`struct thread_master`
+When working with threads that do not use the :c:struct:`thread_master`
 event loop, per-thread buffers can be managed with:
 
 .. c:function:: void zlog_tls_buffer_init(void)
@@ -531,7 +531,7 @@ that they use.
 Basic internals
 ^^^^^^^^^^^^^^^
 
-.. c:type:: struct zlog_target
+.. c:struct:: zlog_target
 
    This struct needs to be filled in by any log target and then passed to
    :c:func:`zlog_target_replace()`.  After it has been registered,
@@ -570,7 +570,7 @@ Basic internals
 
    Allocates a logging target struct.  Note that the ``oldzt`` argument may be
    ``NULL`` to allocate a "from scratch".  If ``oldzt`` is not ``NULL``, the
-   generic bits in :c:type:`struct zlog_target` are copied.  **Target specific
+   generic bits in :c:struct:`zlog_target` are copied.  **Target specific
    bits are not copied.**
 
 .. c:function:: struct zlog_target *zlog_target_replace(struct zlog_target *oldzt, struct zlog_target *newzt)

doc/developer/memtypes.rst

@@ -42,7 +42,7 @@ Example:
 Definition
 ----------
 
-.. c:type:: struct memtype
+.. c:struct:: memtype
 
    This is the (internal) type used for MTYPE definitions.  The macros below
    should be used to create these, but in some cases it is useful to pass a

doc/developer/rcu.rst

@@ -133,9 +133,9 @@ atomic ops & datastructures with other types of locking, e.g. rwlocks.
       become invalid, as another thread may have called :c:func:`rcu_free` on
       them.
 
-.. c:type:: struct rcu_head
-.. c:type:: struct rcu_head_close
-.. c:type:: struct rcu_action
+.. c:struct:: rcu_head
+.. c:struct:: rcu_head_close
+.. c:struct:: rcu_action
 
    The ``rcu_head`` structures are small (16-byte) bits that contain the
    queueing machinery for the RCU sweeper/cleanup mechanisms.
@@ -209,7 +209,7 @@ atomic ops & datastructures with other types of locking, e.g. rwlocks.
 Internals
 ^^^^^^^^^
 
-.. c:type:: struct rcu_thread
+.. c:struct:: rcu_thread
 
    Per-thread state maintained by the RCU code, set up by the following
    functions.  A pointer to a thread's own ``rcu_thread`` is saved in