[framework] Improves performance of BCS implementation

[damirka]

No description provided.

[amnn]

I think it looks great! The only thing that gave me pause was peel_vec_vec_u8 which seems like a slippery slope. I've left a comment there with some suggestions.

Regarding BCS having store -- I think that's fine. It doesn't enable anything that people couldn't already do by converting to bytes and storing those.

[amnn]

I may have missed something, but I think this can be implemented as one loop, rather than peeling two u32s:

public fun peel_u64(bcs: &mut BCS): u64 {
  assert!(v::length(&bcs.bytes) >= 8, EOutOfRange);
  let (value, i) = (0u64, 0u8);
  while (i < 64) {
    let byte = v::pop_back(&mut bcs.bytes) as u64;
    value = value + (byte << i);
    i = i + 8;
  };

  value
}

[amnn]

What are your thoughts on encouraging people who need nested vector constructs like this to use peel_vec_length and a manual loop themselves, for now? Otherwise we risk the API surface exploding with options.

In the longer-term, I could see macros giving you the expressivity you need. If that doesn't materialise, then there are other options as well, like ML-style signatures/functors. There is also the silver bullet of implementing peel<T> as a native function, which can allow for arbitrarily nested T.

[amnn]

@damirka and I chatted about this offline -- this function is morally peel_vec_string, which makes it feel less like the start of a slippery slope to vec_vec_..._vec_{bool,u8,u64,u128}. It's possible that the native function may still be the best approach? Interested to hear people's thoughts on that, but that seems out of scope of this PR, so I won't block its land for that.