A heartbeat folds its lists before it takes the lock

[bjmeetsfo]

Every datanode heartbeat takes the metaserver's global write lock, and
every topology read waits behind it. Five of the things it did under that
lock were folds over the lists the request already carries -- two over the
shard loads, three over the shard states -- so a datanode reporting ten
thousand shards held the lock while it walked that list five times, doing
arithmetic that needed nothing from the state.

Fold them before the lock is taken. The state assignment still happens
inside it, unchanged.

Measured with one thread heartbeating 10k shards continuously while
another reads table topology, 2000 reads, A/B/A on the same box:

before   mean 27.8 us   worst 635.3 us
after    mean  6.8 us   worst 147.6 us
before   mean 26.1 us   worst 497.9 us
after    mean  6.9 us   worst 148.5 us

About four times faster for the reader, and the worst case a quarter of
what it was. Total heartbeat cost is unchanged -- the same work happens,
just not while readers are blocked, which is why measuring the heartbeat
alone shows nothing.

Only two of the five summaries had any test coverage, so the fold was not
verified by anything. Added a test for all five, including that the worst
shard state is a max rather than a sum, and that a later heartbeat replaces
the numbers instead of accumulating them. Breaking one fold fails it.