checkpoint work on truncate.   went back and revised FS truncate to
use open index if we have one.   Need to sort out restoreFDS still.

also was able to remove ppip from LogicalFD::trunc() API as it is
no longer necessary for Container (and never used for Flat/Small file
modes).
oops, forgot about tracking physical offset in data dropping.
XXX: need to update Index API for this too.
add physical offset to the index_add API.
break the phyiscal offset out into its own map (worried about the
unlikely case where we reopen a dropping to append more records...
can that happen?)
finish inital ftrucate code.
 - put layer of indirection (writefh) in the fhs map so we can
   swap out filehandles without having to change the map
 - get the restorefds code for the data droppings in, index
   should handle the index droppings (if any)
XXX: need to look at locking and review case of renaming an open file
put in a renamefd() for ContainerFD.   there are some lingering
issues carried over from the old code that need to be looked at.
a discussion from the code:

  renamefd() is only called from FUSE when a file that is currently
  open is renamed.   the idea is that it should update all in-memory
  references to the old filename to point to the new filename.

  first problem is that we are changing pathcpy without locking
  anything.  need to think through the locking on pathcopy.  second
  problem is that we are not getting all the copies of the pathname.
  concerns: cof->cof_index (do we need an API call for this),
  cof->subdir_path, cof->paths, and cof->rdchunks.   third concern
  is for non-POSIX backends... if we rename a non-POSIX backend,
  could it invalidate open IOSHandles to dropping files?

  it is ok for posix, because if you have this:
    int fd;
    fd = open("/m/foo.txt", O_RDONLY);
    rename("/m/foo.txt", "/m/bar.txt");

  after the rename the fd is still open and connected to the
  renamed file (the state for that is stored in the kernel).  for
  non-POSIX backends, it would depend on how the filesystem
  client library is put together.

  the previous code (before the ContainerIndex layer was
  introduced) had the same kinds of issues, though is it a
  bit different due to some of the API changes (e.g. index
  lookup in the old code returned an int index number, where
  the new code returns a dropping filename).
add plfs_parallel_reader() --- a ContainerIndex version of the PLFSIndex code
(doesn't assume it knows anything about internal indexing data structures)

route Container_fd::read() to new plfs_parallel_reader()

add functions to support plfs_parallel_reader to LogicalFD (this would
be read_taskgen and read_chunkfh)
put in the rest of the read path, with the plfs_parallel_read code.
remove redundant call to index_truncate in Container_fd::trunc.
this calls containerfs_zero_helper() that does the trucate, so it
doesn't need to do the call.

the containerfs_zero_helper() handles three cases (file open --
Container_fd::trunc, file closed -- ContainerFileSystem::trunc,
and file being opened with O_TRUNC).  it makes sense to have the
helper always handle the truncate for all cases so at at high
level it does the same thing (i.e. handle the index).