Risks of API calls within deserialisation constructor of SpeckleApiClient

[nic-burgers-arup]

Step 0:

• I've read the contribution guidelines!

Expected Behaviour

How things should actually work!
When connectors (e.g. SpeckleRhino/GH) deserialise SpeckleApiClient objects, they should be able to do so reliably so that the caller has access to the context (for later saving, etc).
Any API calls to be made by the newly-deserialised SpeckleApiClient should be made outside of constructors to reduce complexity and ensure exceptions thrown in the constructor won't jeopardise the instantiation of the object.

Actual Behaviour

What's actually going on!
Deserialising SpeckleApiClients causes an API call to StreamGetAsync.

Affected Projects

Does this issue propagate to other dependencies or dependants? If so, list them here!
SpeckleGrasshopper deserialises SpeckleApiClients and in so doing triggers an API call to the Speckle server. If any exceptions are thrown, then the object returned is null, and therefore the context (e.g. stream ID) is lost, which means it can't be preserved when the GH file is subsequently saved.

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

1. Save GH file with Speckle receiver or sender
2. Open the pre-saved file

Proposed Solution (if any)

This might be superseded by a wider conversation about whether such a call is even necessary, but assuming it is then I propose moving that API call outside of the constructor into another method, and altering the connectors (like SpeckleGrasshopper) to make a separate new call after the SpeckleApiClient is deserialised.