allow implementations to use error codes for automated actions

[plebhash]

as discussed in #165

more specifically, this PR implements suggestion from #165 (comment)

[plebhash]

with the changes on this PR:

• the spec allows for implementations to take automated actions on error_code strings
• the spec does not force implementations to use specific error_code strings

so we end up in a situation where different implementations could be aiming for the same error_code string, but still be subject to small typo or encoding issues

while that is hard to avoid without major spec changes, SRI can greatly reduce the room for such scenarios by providing types for commonly-used error_code strings

that will be tackled via stratum-mining/stratum#2142

[average-gary]

Does this mean an implementation of JDC that wants to have multiple upstreams, will need to implement all upstreams error codes? How should an implementation learn of error codes for a given upstream?

Edit: answered on call. clients are responsible for implementing handling of each Upstream's unique implementation.

[gimballock]

Some of the issues raised like 'rejecting 100% of your shares' are not necessarily detected by particular error codes, those types of issues could potentially be tracked with lower-level traffic metrics (by adding byte/message count metrics)

• tracking failures to ack or similar spec violations
• tracking excessive data transfers, ingress/egress
• tracking proportion of failed shares to total shares (already possible)

[TheBlueMatt]

good enough

[Fi3]

ok with me