kvs: support splitting values over multiple blobs

[garlick]

RFC 11 defines valref objects in terms of an array of blobrefs, however the current KVS code only supports a single blobref in the array.

RFC 10 specifies that blobs have a maximum size of 1048576, but in our current code base we have

/* Raise the max blob size value to 1GB so that large KVS values
 * (including KVS directories) can be supported while the KVS transitions
 * to the RFC 11 treeobj data representation.
 */
//static const uint32_t default_blob_size_limit = 1048576; /* RFC 10 */
static const uint32_t default_blob_size_limit = 1048576*1024;

Values over the RFC 10 limit should be split when stored and reassembled when loaded. Since a goal of splitting large values is to avoid head of line blocking due to large messages, this split must be handled at the client end, not in the KVS service. This may increase latency, but should reduce the impact of large values on the KVS service end.

commiting large values
The commit API implementation should be changed so that a value larger than the max blob size (as determined by broker attribute) is first split into smaller blobs and directly stored to the content store, then upon receipt of the blobref responses, a valref array is assembled and sent with the commit. Only values smaller than the max blob size should be sent base64'ed in the commit message as all values are now.

looking up large values
The KVS server implementation should return a valref with array size greater than one directly to the client rather than attempting to resolve it to a value in on the KVS server end. The KVS lookup API, upon receiving a valref object instead of a value, then issues load requests directly to the content store, and fulfills the lookup's future when all responses have been received.

appending
The other use case for the valref array is support for appends. That is separately identified in issue #1193.

large directories
dirref objects also can contain blobref arrays. This will have to be tackled before we can lower the max blob size configuration for the instance. Discussed in #1206

[chu11]

It would be possible to implement this by implementing the "lookup" as one set of patches and the "commit" as another set of patches. It of course would be preferable to go in that order as well.

It may seem strange to split it up this feature in this fashion, but by implementing the "lookup" first, a number of internal KVS needs for issue #1193 would be taken care of as a result.

[chu11]

One note on the "lookup". valref objects are supposed to return opaque data to the user. Until #1159 is complete, testing with flux-kvs will generally have to assume json.