do not incrementing/decrementing the opal_progress_event_state.

Per Ralph :
"I noticed that we are incrementing and decrementing the opal_progress_event state.
However, this no longer has any impact whatsoever on the RML as that is running in
the independent ORTE event thread. So all this actually does is impact the MPI layer
by adding an unnecessary overhead."

Thanks Ralph for pointing this :-)

cmr=v1.8.2:reviewer=rhc:ticket=4671

This commit was SVN r31887.

The following Trac tickets were found above:
  Ticket 4671 --> https://svn.open-mpi.org/trac/ompi/ticket/4671

ompi/mca/common/sm/common_sm_rml.c

@@ -77,11 +77,7 @@ mca_common_sm_rml_info_bcast(opal_shmem_ds_t *out_ds_buf,
 
     OBJ_CONSTRUCT(&smr.buf, opal_buffer_t);
 
-    /* bump up the libevent polling frequency while we're in this RML recv,
-     * just to ensure we're checking libevent frequently. */
-    opal_progress_event_users_increment();
-
-        /* figure out if i am the root proc in the group.  if i am, bcast the
+    /* figure out if i am the root proc in the group.  if i am, bcast the
      * message the rest of the local procs. */
     if (proc0) {
         opal_buffer_t *buffer = NULL;
@@ -171,7 +167,6 @@ mca_common_sm_rml_info_bcast(opal_shmem_ds_t *out_ds_buf,
     }
 
 out:
-    opal_progress_event_users_decrement();
     if (NULL != msg_id_str_to_tx) {
         free(msg_id_str_to_tx);
         msg_id_str_to_tx = NULL;