MPI localization in one place

[shssf]

Step 1.
No algorithms changed.
The code copied from one place to other without any modifications. It still have all issues, bugs, memory leaks and etc. Fixing that is the other PRs.

Exception: CSV module slightly changed (in C part) due to MPI related code intermixed with non-MPI. It needs to be addressed but I think it will be in other PR.

[fschlimb]

While I support the idea of isolating transport/messaging technology, the choice of boundaries doesn't seem right. The PR creates a huge transport module which includes much more than just transport: file-read/write, communication (send/recv, collectives), join, shuffle and more.
It would be better to have a module which provides communication/transport functionality only and leave its use to the modules that define the functional semantics (e.g. keep csv-related stuff in csv module, keep quantile computation separate from communication etc).
I don't see how the suggested separation improves the code structure; I actually think it's making it worse.

[shssf]

The PR creates a huge transport module which includes much more than just transport:

Could you please provide an example?
If some small part of non-transport logic is in the transport module for this moment - it can be solved later. I didn't want to do everything in one PR. Currently it is just for simple code move to avoid mpi.h in many modules in HPAT.

[fschlimb]

Things like count_lines, hpat_mpi_csv_get_offsets, get_file_size, get_lower_upper_kth_parallel.

I simply believe the benefit of having less files including mpi.h does not justify impairing the code structure by any degree. A lot of code changes without apparent benefit.

In my mind, a better approach is to gradually move to an abstraction (like what 'hdist_*' was doing) everywhere. Once that's done, we can move it to a properly designed and isolated module. This will never make anything worse.

[shssf]

@fschlimb get_file_size is fully MPI dependent. Other functions looks the same.
All these functions will be implemented as C++ classes tree in my plan. Currently, I don't want to spend time on this. I need to provide ability for user to use HPAT without MPI library. For this, I need to know how many functions are and how they used in HPAT.
This PR localize MPI in HPAT and allow independent work on MPI transport without modification of many HPAT sources.

[fschlimb]

You can just add a comment to the functions to count them. No need to move them around.

There is a difference between the functionality that MPI provides and functions that depend on that functionality. I like the idea of isolating the former, but I don't think we should bundle the latter.

[shssf]

You can just add a comment to the functions to count them

You will have no guarantee you find all functions and their successors.

I like the idea of isolating the former

I also like this idea. How to do this and what first step should be in this approach? How much time it takes (the task - remove MPI dependency)?