Instead of assuming all shares are the same size here, pass in all the sizes.
The protocol doesn't allow immutable shares in a storage index to have
differences in size but it does allow mutable shares in a slot to differ this
way.

Also make it use slot_testv_and_readv_and_writev instead of slot_readv

The behavior should be the same and slot_readv is simpler and less
interesting.

this seems likely to be wrong.
it's probably fine for slot creation but for later writes to a slot it will
probably underestimate the passes required.
we probably have to look at the "data length" of any existing share

Immutable shares are limited to what you can pay for with 10 passes right
now.  This certainly needs to be lifted but until it is we don't want spurious
test failures telling us about the limit.

Mutable shares are limited to what you can pay for with 1 pass right now
because the client doesn't know how to compute the right number of passes and
always spends 1 pass.

Integer division lets this number be zero sometimes.

If enough valid passes are supplied for the amount of storage requested then
allow the operation to succeed.  Otherwise, fail with an error.