GitLab

- watch out for lifetime of bulk handles
- renamed to 'io_access' to avoid collision with access() function
- no need for 'struct whatever' in C++
- calloc of a struct with c++ objects is risky.  implement a
  construcor for bv_client so we can use 'new' like a real C++
  programmer

politely ask the server to shut down.  maybe we'll get gprof or darshan
logs out of the server, for example.

Benvolio was Romeo's (ROMIO) friend.  Abbreviated 'bv'

will catch bugs earlier and it's good practice for libraries

having every process show server stats in an MPI job is overkill

use same "count, address, size" tuple for both memory and file

We need one for client, one for server

Better handle cases where file is not a lustre file or file does not (yet)
exist.

work better for files that don't exist or are not lustre files

- no need to stat twice. oops
- was not setting requested servers when calling compute_striping_info

Lustre headers on Theta (probably other places too) can't be built with a C++
compiler

Haven't profiled this but intuitively it makes sense that we send to all
the targets as fast as we can so they can get to work, then wait for
responses.