docs: better docs, mv doxygen to sphinx

This patch refactors the VPP sphinx docs
in order to make it easier to consume
for external readers as well as VPP developers.

It also makes sphinx the single source
of documentation, which simplifies maintenance
and operation.

Most important updates are:

- reformat the existing documentation as rst
- split RELEASE.md and move it into separate rst files
- remove section 'events'
- remove section 'archive'
- remove section 'related projects'
- remove section 'feature by release'
- remove section 'Various links'
- make (Configuration reference, CLI docs,
  developer docs) top level items in the list
- move 'Use Cases' as part of 'About VPP'
- move 'Troubleshooting' as part of 'Getting Started'
- move test framework docs into 'Developer Documentation'
- add a 'Contributing' section for gerrit,
  docs and other contributer related infos
- deprecate doxygen and test-docs targets
- redirect the "make doxygen" target to "make docs"

Type: refactor

Change-Id: I552a5645d5b7964d547f99b1336e2ac24e7c209f
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>

1 files changed, 23 insertions, 0 deletions

diff --git a/docs/developer/corefeatures/fib/controlplane.rst b/docs/developer/corefeatures/fib/controlplane.rst
new file mode 100644
index 00000000000..8b58d42f5b3
--- /dev/null
+++ b/docs/developer/corefeatures/fib/controlplane.rst
@@ -0,0 +1,23 @@
+.. _controlplane:
+
+The Control Plane
+-----------------
+
+The control plane follows a layered data representation. This document describes the
+model starting from the lowest layer. The description uses IPv4 addresses and
+protocols, but all concepts apply equally to the IPv6 equivalents. The diagrams
+all portray the CLI command to install the information in VPP and an
+[approximation of] a UML diagram [#f1]_ of the data structures used to represent that
+information.
+
+.. toctree::
+
+   neighbors
+   routes
+   attachedexport
+   graphwalks
+   marknsweep
+
+.. rubric:: Footnotes:
+
+.. [#f1] The arrow indicates a ‘has-a’ relationship. The object attached to the arrow head ‘has-a’ instance of the other. The numbers next to the arrows indicate the multiplicity, i.e. object A has n to m instances of object B. The difference between a UML association and aggregation is not conveyed in any diagrams. To UML aficionados, I apologize. Word is not the best drawing tool.