error codes: add hierarchy (#1156)

error codes: add hierarchy

Hierarchy is useful for documentation/classification purposes.
The hierarchy can also be traversed to find find meta data on ancestors.
This is now used in the HTTP Code implementation to inherit HTTP codes.

Note that Previously HTTP codes were specified on the go error type, which
doesn't make sense. Now HTTP codes are attached to an errcode.Code
value via metadata.

Previously I had already created error codes strings with a dot separation
hiearchy. However, that was informal. Now that relationship is validated
and modeled in code. The API still involves giving a dot separated hierachy.
This requires some simple trivial parsing/validation in the implementation
but made for a nicer API than specifying a struct with a parent link.

Some inspiration here was taken from the upspin error codes which are
classified by Kind. When I started adding kinds, I realized I just
wanted to represent them as Codes, which naturally led to hierarchy.
Kind classification can be though of as having many
error hierarchies with a depth of two and a high branching factor.
In our implementation the top level of the hierarchy can be used like a kind, but
we can also create as much or little depth in the tree as we would like.
https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.htm

* simpler representation for metadata

* allow just the child component of the code

* errcode: change CodeStr to a method

This makes it possible to change the storage format.
In particular redundant versus relying on parent traversal

* errcode: don't store the parent code on the child

Its not supported now, but this would would make it possible
to define children first and then define an ancestor.
It also reduces redundant memory usage a little.

docs/development.md

@@ -26,6 +26,8 @@ This takes a while to run. The test suite uses a fork of [gocheck](http://labix.
 
     go test github.com/pingcap/pd/server/api -check.f TestJsonRespondError
 
+# Changing APIs
+
 ## Updating API documentation
 
 We use [RAML 1.0](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md) to manage the API documentation, and the raml file is placed in `server/api/api.raml`. We also use [raml2html](https://github.com/raml2html/raml2html) to generate a more readable html file, which is placed in `docs/api.html`. When a PR involves API changes, you need to update the raml file within the same PR.
@@ -34,3 +36,9 @@ Consider that raml2html depends on various npm packages and can only be run unde
 
     docker pull mattjtodd/raml2html:latest
     docker run --rm -v $PWD:/raml mattjtodd/raml2html -i /raml/server/api/api.raml -o /raml/docs/api.html
+
+
+## Error responses
+
+Error responses from the server are switching to using [error codes](./pkg/error_code/error_code.go).
+The should use the `errorResp` function. Please look at other places in the codebase that use `errorResp`.