First step towards better timeout management for SpeckleApiClient

[nic-burgers-arup]

Step 0:

• I've read the contribution guidelines!

Expected Behaviour

How things should actually work!
When a Speckle server is unresponsive, the deserialisation of SpeckleApiClient should not take up to 100 seconds.

Actual Behaviour

What's actually going on!
The deserialisation of SpeckleApiClient takes up to 100 seconds.

Affected Projects

Does this issue propagate to other dependencies or dependants? If so, list them here!
For Grasshopper files with multiple Speckle senders and receivers, it effectively means they aren't able to be opened when the server is unresponsive.

Reproduction Steps & System Config (win, osx, web, etc.)

• Create Grasshopper file with Speckle receiver(s) and/or sender(s) which receive/send from Server X
• Save file and close Rhino
• Make Server X unresponsive (i.e. not finishing requests)
• Open Rhino, Grasshopper and load previously-saved GH file

Proposed Solution (if any)

I propose reviewing this to make the default a few seconds for all calls except the bulk stream object GET calls.
These could be overwridden from the outside (i.e. SpeckleGrasshopper) but since there is an API call made during the constructor during deserialisation, this isn’t possible without a bit more refactoring, which leads me to think some wider consultation would be in order.
When a timeout does occur, in order to align with the approach of throwing SpeckleExceptions for other reasons, I propose adding one for time outs.
This does cause the deserialization of SpeckleApiClient by SpeckleGrasshopper to fail and means the stream data is lost – i.e. when you save the GH file again, no Stream IDs are preserved – so it’s not ideal, but just the minimum to mitigate the risk and to start the conversation about some changes in SpeckleCore.