Gateway-MT centric holistic error mapping plan

[wthorp]

Create an internally review (only Team Edge) a plan to map metainfo errors through to Gateway-MT. Possibly involving an import from another package and making sure DRPC handles this all well.

[wthorp]

There's a slight overlap here with errors that serialize differently each time; they're very bad / annoying for metrics.

[mniewrzal]

If we will have a list of the most common errors we can start adding uplink library to support them.

[wthorp]

@mniewrzal We have a metric in Chronograph that helps us detecting and responding to "unmapped errors" - sources of HTTP 500s in Gateway; we tend to improve an new error mapping per sprint. We loosely feel like we could have a better architectural pattern / plan to preempt these issues, however. It would be nice if every error had a corresponding class and constant string representation, to make them easy to catch and metric. Perhaps there's a tool which can analyze code paths and return a list of all possible errors. Failing that, perhaps we'd benefit from a big list of possible errors in each package. Centralizing errors like this, while having its own drawbacks, would certainly create a sense of order in how errors are best handled.

[wthorp]

https://github.com/storj/uplink/issues/72