Resolving Crashing & CPU-spinning issues

There are two issues addressed in this release:

• Crashing issue when systems with bad/corrupt timezone information
• Spinning at a whole CPU core if there were failures writing the events to disk before uploading

Crashing with bad timezone information

Based on a report from a wonderful customer, it appears that there are certain situations where this call -- when supplied with the Etc/UTC timezone will cause the platform to throw a 'Catastrophic Error' COMException. It's unclear why -- the customer reported it on Windows 10, 1803 when in the Australian region/timezone.

While unable to repro locally on any of my devices, it was confirmed that using the 'no timezone adjustment' version of the API results in a successful stringification. So, lets try the 'right way' (Since Mixpanel says to supply this information in UTC), and if it fails, accept that the time could be off by ~12 hours in either direction.

Spinning a CPU if unable to write to disk

The original design of this component intended to always write to disk before trying to upload; this was to allow for resilience in the face of a crashes or quitting the app before the queue was drained. However, it became apparent that if the events couldn't be written to disk, it would spin forever.

This update no longer forces them to successfully write to disk before handing off to upload -- it still tries to write first, and only after completing (in success or failure) does it hand it off to the queue.

Improving offline / intermittent connectivity behaviour

This release address a particularly nasty issue with how MixpanelClient handled offline / poor connectivity.

Specifically, if you were offline or unable to actually reach Mixpanel, this background thread sending to the service would spin forever, consuming a whole CPU core.

This address that by adding a back off on the retry, which will ultimately stop processing items if the network is unavailable. If the network is actually offline, it will resume processing on the next network state change. Otherwise it will wait for the queue to be restarted for other reasons -- resume after suspend, app restart etc.