add error_code constants

[plebhash]

close #2142

companion stratum-mining/sv2-apps#495

[GitGab19]

I looked on the specs and reported almost on every "message" the error_code(s) that we have there, to simplify the review and being sure we're covering all we have on the specs.

That said, I think my initial understanding was to define the error codes (as constants) only for the ones which are explicitly defined in the current specs.

But reviewing this PR made me realize that probably your goal was to cover all the codes we have on the specs + everything we are already using at the application level (which very likely would be useful also for some adopters).

Is my understanding correct?

[plebhash]

I looked on the specs and reported almost on every "message" the error_code(s) that we have there, to simplify the review and being sure we're covering all we have on the specs.

That said, I think my initial understanding was to define the error codes (as constants) only for the ones which are explicitly defined in the current specs.

But reviewing this PR made me realize that probably your goal was to cover all the codes we have on the specs + everything we are already using at the application level (which very likely would be useful also for some adopters).

Is my understanding correct?

as of today, SRI already implements error_codes that are not explicitly listed on the spec

this PR covers all error_codes from current SRI

---

I cannot say I introduced all error_codes that are not listed on spec, but I do remember introducing many

I've always treated the error_codes listed on the spec as merely suggestions, not a comprehensive list

so whenever I was faced with some edge case that the spec didn't explicitly list, I just established the error_code on SRI without going through the bureaucracy of proposing spec change (which would severely slow down whatever I was working on SRI)

[GitGab19]

I see, and I guess it makes sense.

My question now is: should we have constants for all the error-codes which are currently listed on the specs? Even if they are not currently used by our implementation?

[plebhash]

@GitGab19 FYI since your last review I'm doing some additional changes here, which are one extra step aligned with the vision described in #2149 (comment)

more specifically, with 4d80cc5 I'm making sure that error enums of channels_sv2 (e.g.: ExtendedChannelError, StandardChannelError, and most importantly ShareValidationError, all carry a (&'static str)

but not all error variants carry a (&'static str), so hopefully Rust Docs comments should make the pattern clear:

/// Variants carrying `&'static str` are intended to be used as `error_code` values in the response message.
/// 
/// Variants without `&'static str` SHOULD lead to a client disconnection or application
/// shutdown.
/// ...

[plebhash]

reproducing #2151 (comment):

Aren't we missing invalid-job-param-value-version, invalid-job-param-value-wtxid_list, and invalid-job-param-value-excess-data here?

perhaps @GitGab19 's intention was more of a rethorical question to point out the issues we discussed around invalid-job-param-value-{} pattern

nevertheless, it might be worth addressing the question for the sake of clarity on this PR

DeclareMiningJob.{version,wtxid_list}

those parameters are both validated during checkBlock IPC call, and on failure result in a generic error_code = "invalid-job"

maybe one could argue that those deserve more granular error_codes, which is a fair point

however, I don't really have a clear idea if/how that could be easily achieved inside bitcoin_core_sv2, and I don't think that should be addressed on the scope of this PR

DeclareMiningJob.excess_data

so far this parameter has never been used on SRI, and I don't know what kind of edge cases could arise from it

[GitGab19]

Now it looks way better, very good job!

I only left a couple of nits.