Increase max ConsumerWorkService block size to 256

[michaelklishin]

As suggested in #813. This has a few
minor effects on consumers:

• A low single-digit % throughput gain
• A comparable reduction in mean consumer latency

In general, it makes sense that consumers operating at peak throughput
should run operations in blocks close to the QoS prefetch used.
Since we usually recommend a value of 100-300 for environments that
focus on throughput, the new default of 256 makes sense.

The only negative effect I can think of a slightly higher GC pressure
which can increase variability of the aforementioned metrics.

Using development builds with PerfTest

To install a development version of this client locally, use

./mvnw clean package -P uber-jar -Dgpg.skip=true -Dmaven.test.skip

then change PerfTest dependency in pom.xml to use 6.0.0-SNAPSHOT or whatever version
you designate to this PR locally, and produce an uberjar:

./mvnw clean package -P uber-jar -Dgpg.skip=true -Dmaven.test.skip

then run it like so

java -jar ./target/perf-test.jar --queue block-size-256 -x 1 -y 2 --qos 256 --id "block-size-256"

and compare it to a GA version, e.g.

java -jar perf-test-ga.jar --queue block-size-16 -x 1 -y 2 --qos 256 --id "block-size-16"

[lukebakken]

Wait for a 👍 from @acogoluegnes on this one!

[acogoluegnes]

I did not notice any significant nor reproducible improvement after some local testing, but this block size is better aligned with our QoS recommendations, so I'm OK to merge.