Fixup VIS preconditions

[Dan Bonachea]

VIS chapter preconditions include imprecise statements like the following:

All destination addresses must be global_ptr<T>’s originating from the same rank.

All source addresses must be global_ptr<T>’s originating from the same rank.

These should be cleaned up to use proper terminology ("originating from" is not a defined term).

Also for VIS rput_*_then_rpc:

Completion of the operation triggers a rpc_ff consisting of remote_completion_func bound with remote_completion_args to the rank owning the destination addresses.

Upon completion of the puts, the rank owning dest_base is delivered an rpc_ff of remote_completion_func called against remote_completion_args

"owning" should probably be "with affinity to", and the terminology for rpc_ff func/arg binding should be cleaned up and normalized

There's also an important secondary issue here that John just fixed for contiguous rput_then_rpc, which is how to handle the cases where the VIS payload was empty.

There are several distinct cases here:

1. For fragmented and fragmented_regular: the iterators are empty, ie returned ZERO global_ptr<> destination addresses.
2. For fragmented: the iterators returned a set of tuples where the size was always zero
3. For fragmented_regular: src_run_length == dest_run_length == 0
4. For strided: Dim template parameter is <= 0 (should probably be prohibited)
5. For strided: Any element of extents[i] is zero

GASNet VIS accepts all of these cases and treats them as no-ops, but there is no _then_rpc variant in GASNet VIS.

Each of these cases in the UPC++ _then_rpc function needs to either be prohibited by precondition or (if it makes sense) ensure we have a well-defined semantic for which rank runs the rpc.

[Dan Bonachea]

One possible resolution to the VIS_then_rpc target ambiguity is to add a intrank_t recipient argument to all the VIS rput*_then_rpc functions, and require that all global_ptr<>'s in the metadata have .where() == recipient. This adds a small amount of redundancy to the common case, but with this change, we always have a well-defined target for the rpc, even for the corner cases where the VIS payload turns out to be empty.

[Dan Bonachea]

Add to the fix-it list for rget_fragmented(regular):

a sequence of destination addresses of T const *
...
DestIter could be an iterator over elements of type std::pair<T const*, std::size_t>

in both places should be T * (no const)

[Former user]

I'm going with adding the explicit recipient.

[Dan Bonachea]

New recipient argument looks good.

3-4 of the other issues I raised above are still unresolved:

1. Use of undefined term "originating from"
2. Use of undefined term "owning"
3. "destination addresses of (T const *)"
4. rpc_ff func/arg binding text should possibly be normalized to match similar text elsewhere

The first two involve preconditions that should be altered to refer to "affinity" or a pointer.where().

[Former user]

Wow thank you. Sloppy sloppy.