Fix panic in sim2h server

[lucksus]

PR summary

Add Sim2h::get_or_create_space() instead of expect()ing it to be there.
Fixes this panic: https://gist.github.com/lucksus/0abe24e4397d6f100fd8f64df0f7f093

..which can happen if the last node in a space leaves just when a message associated with that space gets processed.

testing/benchmarking notes

( if any manual testing or benchmarking was/should be done, add notes and/or screenshots here )

followups

The code was assuming to be run in a single thread which would have made these assertions be always true (checking the space is the first thing that is done with incoming messages and any function that gets called to process the message assumes its space to exist). With @neonphog's new websocket implementation we got multi-threaded and the space could have been dropped while our thread is still processing it an. Rust helps a lot in pin-pointing code that would have problems with multiple threads - nevertheless, we should take a look at the sim2h server code again if the assumption of a single thread is still baked in somehow.

For instance: could dropping the space while a thread is processing a message lead to gossip failiures?
If so: should we (read-)lock the space when a thread enters so that it does not get dropped?

I would leave these as follow-ups so we can get this fix in quickly as it makes sim2h instances crash sometimes.

changelog

• if this is a code change that effects some consumer (e.g. zome developers) of holochain core, then it has been added to our between-release changelog with the format

- summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)

documentation

• this code has been documented according to our docs checklist

[zippy]

good catch

[neonphog]

woot, good fix - fwiw, I think most everything else should still be Okay, since the messages still come in on a single channel, they'll be queued in order. But certainly something to keep in mind.