rfq+rfqmsg: add structured price oracle error codes

[jtobin]

Adds some structure to price oracle error codes, along with some custom handling for them. In particular, a code of '1' now corresponds to an 'unsupported asset' error, which, considered a 'public' error, is forwarded in the customizable message field of the reject messages sent to peers. An error with any other code continues, at present, to be treated as an unspecified error.

Resolves #1749, #1326.

(This is a refinement over the closed #1751, which forwarded errors indiscriminately.)

[coveralls]

Pull Request Test Coverage Report for Build 20850480246

Details

• 16 of 67 (23.88%) changed or added relevant lines in 4 files are covered.
• 77 unchanged lines in 18 files lost coverage.
• Overall coverage decreased (-0.02%) to 56.974%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
rfqmsg/reject.go	3	9	33.33%
rfq/negotiator.go	12	23	52.17%
rfq/oracle.go	0	12	0.0%
taprpc/priceoraclerpc/price_oracle.pb.go	1	23	4.35%

Files with Coverage Reduction	New Missed Lines	%
asset/group_key.go	2	72.15%
fn/iter.go	2	62.07%
mssmt/compacted_tree.go	2	77.65%
rfq/negotiator.go	2	55.73%
tapdb/addrs.go	2	76.56%
tapdb/mssmt.go	2	90.45%
tapdb/multiverse.go	2	82.14%
tapdb/sqlc/transfers.sql.go	2	83.33%
commitment/tap.go	3	85.19%
proof/verifier.go	3	85.57%

Totals
Change from base Build 20833518484:	-0.02%
Covered Lines:	65556
Relevant Lines:	115063

---

💛 - Coveralls

[GeorgeTsagk]

in the future would we append to this switch all the cases for codes that are considered public?

[GeorgeTsagk]

If I read the iota list of all error codes I don't really have some information source as to whether they are public or internal error codes.

We could follow a convention that all non-zero codes are public (with appropriate docs in the definitions ofcs)

Or further extend the oracle error with a direct Internal bool flag, that explicitly indicates whether this code/msg should be shared or not

[jtobin]

Yeah I like that latter idea -- let the oracle indicate whether the error is intended to be public/private. 👍

[jtobin]

Coming back to this: I decided to axe the 'public' flag for this changeset, so customRejectErr is again the arbiter of whether we forward opaque or more detailed error messages, based on the code value. I do like the 'public' idea, in the meantime, as a kind of hint from the oracle as to whether an error is appropriate to relay, so maybe I can make another argument for it in the future.

I think there's no immediate need to codify a hard public/private scheme at the moment. We may want other nonzero codes to be considered private, for example. I'd be inclined to pick that issue up again when it's time to add/handle more codes.

[ffranr]

I've taken another look through this.

IMO needs commit squash and then we can review the set of commits which will be merged.

[lightninglabs-deploy]

@GeorgeTsagk: review reminder

[GeorgeTsagk]

LGTM