Generate RPC API documentation

[cornelius]

This commit adds full documentation for all unit-e RPC calls. The information is generated from the help information from the client itself so it's easy to keep it up to date with the released versions and with the latest development state. The commit represents the current state of dtr-org/unit-e master.

It's done in a generic way so this could also be applied to upstream. This might be a nice contribution to the documentation upstream.

There are still a few things missing and a few glitches:

• An intro to the RPC mechanism and how to use it is missing. Most of it can be taken from the upstream documentation.
• A few commands with complex arguments are not explicitly processed so that the information is rendered without proper formatting.
• There are a couple of commands which have notes in the help which are different from how other commands are doing it. These notes are currently missing from the generated documention.
• JSON structures are shown literally. They could also be parsed to allow better formatting.
• In general the formatting can be improved to make things clearer.

These things will be addressed in subsequent commits.

Some notes for reviewing this pull request:

• The most interesting part is the resulting documentation. This should be good enough for a first iteration. That's what I would like to achieve with this pull request. There is some more work needed, but it probably is better to do that with additional pull requests to not further extend the scope and size of this pull request (which already is big enough in itself ;-)
• You can view the documentation by running make html and then point your browser to _build/html/reference/rpc/index.html. This requires Sphinx to be present to generate the HTML but you don't need any server as it's all static HTML.
• The content of the documentation is in the end taken from the unit-e sources so you don't need to review that as part of this pull request. If you notice things which should be fixed we can do that separately via issues and pull request for unit-e.

[cmihai]

Nit: I would run autopep8 on all the committed Python files, but that's just a personal code style preference.

[Gnappuraz]

It looks like there is an indentation issue

/home/travis/build/dtr-org/docs.unit-e.io/reference/rpc/createrawtransaction.rst:23: WARNING: Unexpected section title.
[
{
/home/travis/build/dtr-org/docs.unit-e.io/reference/rpc/logging.rst:17: WARNING: Unexpected indentation.

[cornelius]

There's the just the question of how/whether to document "hidden" RPC methods, which don't have a help text (for example, proposerstatus, used by the wallet GUI).

What's the rationale for "hiding" these RPC methods? I tend to think that if they exist and can be accessed they should also be documented. If they are not supposed to be used for certain purposes this could be part of the documentation.

Also, can/should we host all the documentation somewhere for easier access? I could bring a Raspberry Pi to act as a fileserver, maybe?

The documentation is already served on http://docs.unit-e.io. It's currently password protected. The master branch is automatically pushed there.

Nit: I would run autopep8 on all the committed Python files, but that's just a personal code style preference.

No, that's a good point. Maybe we should document our Python style guide somewhere. We have that for C++ in a very good way, but for Python this is not very explicit (and it could be as simple as run xyz on the code to get proper formatting).

[cornelius]

It looks like there is an indentation issue

/home/travis/build/dtr-org/docs.unit-e.io/reference/rpc/createrawtransaction.rst:23: WARNING: Unexpected section title.
[
{
/home/travis/build/dtr-org/docs.unit-e.io/reference/rpc/logging.rst:17: WARNING: Unexpected indentation.

I'll fix it.

[cornelius]

No, that's a good point. Maybe we should document our Python style guide somewhere. We have that for C++ in a very good way, but for Python this is not very explicit (and it could be as simple as run xyz on the code to get proper formatting).

I see that upstream has done some work on this in the developer notes as well as the linter code so I suppose we will inherit some of that with the next upstream merge.