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

[TheBlueMatt]

Honestly this seems like a recipe for people complaining about incompatibility. If a pool is rejecting shares, it's important that clients switch to a fallback irrespective of what error message they're getting back.

It's still not really clear to me what automated action we expect clients to take based on errors - the only automated action you can really ever do is switch to a fallback pool and notify the operator somehow, and that needs to be independent of the error code itself.

We should clarify this, at least, to mention that because pools may use different error messages it's critical that clients' fallback behavior is not (materially) impacted by the error string itself.

[plebhash]

added 69565f4 with the following sentence:

Essential fallback or recovery behavior MUST NOT rely on receiving a specific error code.