Should collectives on SHMEM_TEAM_INVALID be no-ops?

[nspark]

Currently, the collectives intro says:

If an invalid team handle or SHMEM_TEAM_INVALID is passed to a team-based collective
routine, the behavior is undefined.

Should we leave this as-is, or should collectives on SHMEM_TEAM_INVALID be treated as no-ops?

Some points in favor of treating them as no-ops:

• Collectives are enough of a "heavyweight" operation that I'm not concerned about the branch.
• Elsewhere, we define most (all?) team-based operations to be no-ops for SHMEM_TEAM_INVALID. This would make collectives consistent with those other operations.

[naveen-rn]

Elsewhere, we define most (all?) team-based operations to be no-ops for SHMEM_TEAM_INVALID.

I'm not sure, where @nspark came up with this conclusion. If this is correct, then the usage of shmem_team_ctx_create is incorrect in this example https://github.com/gmegan/specification/blob/teams/example_code/shmem_team_context.c. Implementations should handle the INVALID scenario, and there shouldn't be any check necessary in the example.

[nspark]

At the 5/21 reading, it was noted that the then-current draft had inconsistent language toward handling invalid teams; e.g., "If team is invalid, the behavior is undefined. If team is SHMEM_TEAM_INVALID, the return value is 1."

Absent any feedback from anyone else, I tried to reconcile the two where the goal was consistency; tipping the scales for special handling of SHMEM_TEAM_INVALID was to simplify some behavior for users (akin to free(NULL) being well defined). See 0034139, 65faf2b, be43a4b for examples. There are likely some routines that I missed these changes; shmem_team_translate_pe may be one.

This created the situation in which most team-based operations were no-ops for SHMEM_TEAM_INVALID. If that's not what we want to settle on, I'm fine rolling back those changes.