Don't use util::generateGid() for MPI messages

[csegarragonz]

The message ID in the MPIMessage protobuf objects is not necessary to guarantee execution integrity. It is just useful for logging and debugging purposes. Further, given that each message has also a sending and receiving rank, a per-rank counter suffices to uniquely identify them. As MPI ranks are single-threaded, we can get away with a thread local counter.

Note that, profiling in high contention experiments, showed a non-negligable amount of time spent in generateGid(). I am not sure what is causing it, but we definately don't need it in the MPI message, thus I remove it.

[Shillaker]

The lock acquired in generateGid should only be acquired once per host (as it's just used to set a single static variable), so I'm very surprised that it would be a source of contention. How do you know it's the lock and not the other stuff that happens in that method? In what sort of workload is that the case?

If there is contention it's most likely that the code is broken somehow. Rather than just dodge the issue for MPI, it would be better to fix the underlying GID bottleneck if there is one. Perhaps we could try switching it to use call_once rather than the mutex-based setup we have at the moment, or use a static initialiser, e.g.

unsigned int generateGid()
{
    static size_t gidKeyHash = [](){
         std::string gidKey = faabric::util::randomString(GID_LEN);
         return std::hash<std::string>{}(gidKey);
    } ();
    
    // Existing method   
}