change(rpc): Update getblock RPC to more closely match zcashd

[conradoplg]

Motivation

Currently zebra has partial support for getblock() and it mostly targets lightwalletd usage. For zcashd deprecation we want it to match zcashd more closely.

Specifications & References

zcashd RPC docs

Solution

Based on #8967

Since getblock() returns basically a superset of getblockheader(), I change our getblock() to call getblockheader() for all the shared fields.

Work on returning the additional non-header fields will be done in separate PRs.

I also changed getblockheader() return codes since whatever error it returns is now returned by getblock(), and we have committed to error codes in our snapshots. I also added the -5 error code which can also be returned by zcashd.

Since the previous behaviour can be still useful for performance reasons, I moved it to be carried out when verbosity=3 is used. It would be a simple change to lightwalletd. I'm not sure about the specific number though, should we use something farther off?

This also adds ZEBRAD_EXTRA_ARGS to zcash-rpc-diff because I was stubborn and wanted to make it work with cookie authentication 😆 Let me know if you'd prefer it in a separate PR, but it seems simple enough.

Tests

I adjusted the existing vectors.rs tests and updated the snapshots. I also tested it manually and with zcash-rpc-diff; the current diff is that size, blockcommitments authdataroot, chainhistoryroot, chainwork anchor, chainSupply and valuePools are not yet being filled; and verbosity=2 is still the same as 1 (i.e. tx is not expanded)

Follow-up Work

• Check which of the remaining fields are truly required (some of them are undocumented). I'll ask the deprecation group.
• Created issues for the fields we are going to work on

Additional information to put in Changelog

### Performance Regression

The `getblock()` change described below will impact lightwalletd operators who
back it with Zebra. The initial sync performance will drop unless you change
the `getblock()` call to use `verbosity=3`. See below for details.

### Changed

- The `getblock()` RPC now supports all the fields also returned by `getblockheader()`.
  The old partial support is now moved to `verbosity=3`; it might be useful for
  lightwalletd if you want to keep the same initial sync performance as before
  (you will need to changed lightwalletd source code to use `verbosity=3`)

PR Author's Checklist

• The PR name will make sense to users.
• The PR provides a CHANGELOG summary.
• The solution is tested.
• The documentation is up to date.
• The PR has a priority label.

PR Reviewer's Checklist

• The PR Author's checklist is complete.
• The PR resolves the issue.

[arya2]

This is looking good! I left some suggestions in #9008.

Since the previous behaviour can be still useful for performance reasons, I moved it to be carried out when verbosity=3 is used. It would be a simple change to lightwalletd. I'm not sure about the specific number though, should we use something farther off?

The new behaviour seems performant enough for lightwalletd to continue using verbosity = 1. I don't think we need to mention a performance regression in the changelog either.

The performance issue before (fixed in #5307) was that it was reading all of the block's transactions, the database queries added here should be quick, and, if they still have a measurable impact on lightwalletd sync performance, can be optimized easily (like by parallelizing or unifying state requests and maybe using an iterator to get the block hashes at height/height.next()) .

(Though we should make sure to cache block sizes by hash in a new column family when adding that field to avoid reading, deserializing, and then serializing the entire block to get its size.)

[oxarbitrage]

It looks good, i made a few comments and documentation suggestions.

[oxarbitrage]

I am confused here. I only see the verbosity cases 0, 1 and 2 in the method code.

[conradoplg]

Initially I introduced a new verbosity but Arya pointed out that wasn't needed, and I forgot to update this. Thanks! Fixed in 1013611

[oxarbitrage]

Can you explain more what are the todo here and in the next ?

[conradoplg]

Sure! I removed the TODOs in 1013611 to make it less confusing (I forgot to clean them up) but they are:

• Supporting returning detailed transaction objects with verbosity=2 (that will be getblock: return transactions details with verbosity=2 #9024)
• Actually computing and returning the size of the block (that will be getblock: return the size field #9020)