Improve `zcash_serialized_size()` performance

[arya2]

Motivation

This method is needlessly slow, Zebra now avoids reading large blocks from disk to respond to RPC methods, but every time it writes a block to the chain state, it counts the number of bytes used to represent its serialized encoding.

It's not a significant computation, but it does this sequentially, and it's easy to fix.

Design

Block::zcash_serialized_size

fn zcash_serialized_size(&self) -> usize {
    self.header.zcash_serialized_size() + self.transactions.zcash_serialized_size()
}

Header::zcash_serialized_size

fn zcash_serialized_size(&self) -> usize {
    /// Size of a serialized zcash block header except for the equihash solution
    const HEADER_SIZE: usize = 140;

    let solution_size = match self.solution {
        equihash::Solution::Common(_) => equihash::SOLUTION_SIZE,
        equihash::Solution::Regtest(_) => equihash::REGTEST_SOLUTION_SIZE,
    };

    solution_size + HEADER_SIZE
}

Vec::T::zcash_serialized_size

fn zcash_serialized_size(&self) -> usize {
    let len_size = CompactSizeMessage::try_from(self.len())
        .expect("len fits in MAX_PROTOCOL_MESSAGE_LEN")
        .zcash_serialized_size();

    self.iter()
        .fold(len_size, |acc, t| acc + t.zcash_serialized_size())
}

The serialized size of a transaction can also likely be determined without fully counting every byte in its encoded representation (or perhaps without counting any bytes, if all of the encoded sizes can be determined based on len fields).

[zmanian]

I'd like to take this on.

Proposed approach:

The key insight from the issue is that transaction serialized sizes can be computed from field lengths without iterating byte-by-byte through the encoded representation. For each transaction version:

1. Fixed-size fields (version, lock_time, expiry_height, etc.) contribute constant sizes
2. Variable-length collections (inputs, outputs, joinsplits, spends, actions) contribute CompactSizeMessage(len) + per-element sizes
3. Per-element sizes can themselves be computed from inner field lengths (e.g., a transparent input's size is determined by its script length, an orchard action is fixed-size)

This turns the O(serialized_bytes) computation into O(num_elements) with small constants, and the Vec<T>::zcash_serialized_size fold over transactions can be parallelized with rayon if warranted (though the arithmetic-only version may be fast enough that parallelism is unnecessary).

I'd implement zcash_serialized_size() directly on Transaction (and its inner types like transparent::Input, transparent::Output, sapling::ShieldedData, orchard::ShieldedData) using field-length arithmetic rather than the current approach that delegates to the generic Vec<T> serialization fold.

Happy to hear if there are concerns or preferred approaches before I start.