sharedMem: Fix race condition and sending uninitialized values to the server

[tidely]

Fixes a race condition inside of the sharedMem.insert method. The lock was not being held when the index of the next value was changed, meaning a thread could instantly overwrite the previous value during high contention.

Fixes an issue where a default value of -99.9 was being used to indicate an uninitialized field, however the sharedMem.get function would check for 99.9.

I'd also like to note that previously initialized values will still remain inside of the memory, meaning when writing a message with a single value to a field which previously contained 3 values, the get method will think it is a 3 valued field, since the values are never reset and send them over the network. This can be fixed by a later PR.

This implementation of a custom shared memory shows how error prone writing custom data structures is. Additionally the shared memory is currently only used to relay messages over TCP once meaning the whole thing could be replaced by a multiprocessing.Queue. This introduces slight serialization overhead, which should be negligible. Alternatively queue.Queue could be used, since the client uses threads for networking code anyway, not full processes.