Initialize the mpi_errcode argument to MPI_Abort in MPAS's log_abort routine

[mgduda]

This PR initializes the mpi_errcode argument to MPI_Abort in several MPAS routines.

The mpi_errcode variable in MPAS's log_abort, mpas_dmpar_global_abort, and mpas_dmpar_abort routines that is passed as the errorcode input argument to MPI_Abort was previously uninitialized, leading to the potential use of uninitialized memory in MPI_Abort (or in routines called by MPI_Abort).

In practice, the uninitialized value in mpi_errcode caused no problems, though when running MPAS with valgrind's memcheck tool, it could lead to the generation of (possibly numerous) uninitialized memory errors in the log from memcheck.

Note that although this PR initializes the mpi_errcode variable with a value of 6, corresponding to the POSIX SIGABRT signal number, the specific value is probably not important.

[islas]

Would it make sense to use a value of 6 (SIGABRT) for mpi_errcode? It could allow for catching and cleaning up elsewhere (e.g. in a coupled situation) which may be a good or bad thing.. Same for potentially creating core dumps which most people may not find useful. All assuming the MPI implementation utilizes and forwards the errcode passed in.

SIGKILL is the most straight-forward and simplest.

Just some thoughts.

[mgduda]

Sure, we can use SIGABRT. I'm not actually sure that MPI_Abort uses the errcode value to send any signals, and most likely the value provided is just used as the exit code for the process, so in that sense any non-zero value should do. But, since we are aborting, we might as well use an exit code that corresponds to SIGABRT.

I'll push an update shortly.

[mgduda]

Actually, I found a couple of other places in MPAS where we call MPI_Abort without intializing errcode. In practice, I think it would be rare that we'd invoke MPI_Abort from these other places, but I'll address them with an update to this PR just to avoid future issues.