Refs #4682 - This commit fixes c_flush test failure in the ibm test suite for Portals 4 OSC

cmr=v1.8.2:reviewer=tkordenbrock:subject=Move r32112 to v1.8.2 branch
This commit fixes #4681 - ibm c_fence_lock hangs

cmr=v1.8.2:reviewer=tkordenbrock:subject=Portals4/MTL hanging fix
fix sort_devs_by_distance in btl/openib

The distances as returned by hwloc_get_whole_distance_matrix_by_type are typ float.
This patch handle all distances as float.

cmr=v1.8.2:reviewer=miked
fix sort_devs_by_distance in btl/openib

no need to #include <math.h> ...

cmr=v1.8.2:reviewer=miked:ticket=4759
Per request from Jeff, slightly modify the show_help message as the precise name of the NUMA-containing packages differs based on OS and distro

cmr=v1.8.2:reviewer=jsquyres:subject=modify show_help message
Remove useless variables.
ompi_mpi_abort had one extra argument that was never used. Clean it up.
ompi_mpi_abort: fix corner cases, simplify logic

I recently found a case where ompi_mpi_abort() segv's:

{{{
$ mpirun --mca btl non_existent_btl_name ...
}}}

In this case, the BML init fails because we have no paths to any
peers.  It calls ompi_mpi_abort(), but this is before ompi_comm_self
has been setup.  ompi_mpi_abort() assumes that if the comm parameter
is != NULL, it can be used.  But since we aborted so early in
MPI_INIT, that's a false assumption.

(note that this isn't happening on v1.8 because the check for
INIT/FINALIZE in ompi_mpi_abort() is a little different.  Hence: this
is a trunk issue -- at least for now)

When fixing this problem, I noticed a few other problems in ompi_mpi_abort():

* the group access was incorrect (it didn't use accessor functions)
* it wasn't clear that ORTE's ompi_rte_abort_peers() returns
  NOT_IMPLEMENTED and falls through down to ompi_rte_abort()
* the check for my proc in the communicator was a little more
  complicated than necessary
* the logic for checking for aborts early in MPI_INIT wasn't right
* some comments were stale
* the hostname output in error messages would be NULL if MPI_FINALIZE
  had been invoked
* it was possible to abort, but still exit with a 0 status

This commit fixes all of the above problems, and makes the logic a
little more straightforward.  Thanks to Ralph Castain and George
Bosilca for the assists with this patch.
Remove a potential race condition - we'll cleanup the local children when we are all done
Move all collective id's into the attributes and let the job pack/unpack take care of them instead of singling them out. Add the envars just prior to forking the children instead of into the launch message itself. Remove a few #if CR as the attributes functionality can handle this condition now.
usnic: make this show_help message like the others

There's no need for the port number (since usNIC has no port numbers),
and make the wording the same as other help messages.

Reviewed by Reese Faucette.

cmr=v1.8.2:reviewer=ompi-rm1.8
usnic: EHOSTUNREACH means there is no route

ibv_create_ah() can also return EHOSTUNREACH, which means that there
is no route to the peer.  Treat that as a non-fatal warning.

Reviewed by Reese Faucette.

cmr=v1.8.2:reviewer=ompi-rm1.8
Silence warning
As discussed at the OMPI developer's meeting, add functions to start, stop, and restart libevent-driven progress threads. Critical NOTE: if you don't have a file descriptor event defined for your progress thread, it will spin hard! Accordingly, the "start progress thread" function has a boolean parameter you can use to request that the function automatically create one for you.
As discussed during the Open MPI meeting, make ompio the default parallel I/O
library on the trunk in order to expose it to more testing.
Fix the cornercase with MPI_PROC_NULL persistent requests.

This corner case is now handled in the pml so the same code
is invoked for both MPI_Start and MPI_Startall.
This also correctly report an error if MPI_Startall is invoked twice
on a MPI_PROC_NULL persistent request.
Cleanup : fix the cornercase with MPI_PROC_NULL persistent requests.
Ensure that the progress thread tracker properly cleans up the blocking event, if set. Also, use the blocking event to help wake up the progress thread for quick shutdown as some threads can be blocked in a long-running call to select.
When a user asks for cpus/rank > 1 and only has one slot, we need to ensure we always map at least one process when they don't tell us -np

cmr=v1.8.2:reviewer=rhc:subject=correct num_procs in corner case
openmpi.spec: several minor fixes

Thanks to Oliver Lahaye for supplying the patch.