Serialize TelemetryItem before sending it to persistence.

[ElektrojungeAtWork]

I didn't go the "deep copy on main thread" way as:
a) deep copy might create a lot of overhead (and it's generally a bad idea to do a lot of work on the main thread
b) is error prone
c) would have made it necessary to implement serializable & would have required touching our contract files

So I followed @crystk s idea and we now serialize directly after calling enqueue(...) and then have a queue of strings and persist them. Persistence is no longer in charge of serialization but just fileI/O.

Tests pass and from my POV it works, but I wasn't able to verify the bug in the first place.

I'd be great if @chrwend or @scsouthw have a look and merge

[southwood]

thanks @TroubleMakerBen, I like the change but I think we might still have problems with concurrent access using this approach (although it will be less likely to occur).

Making a deep copy of the properties/measurements would not be terribly expensive. The contents are strings and numbers so it's mostly the cost of constructing the map object. Doing this in the track methods would resolve the issue.

[ElektrojungeAtWork]

@scsouthw implemented the deep copy approach. We probably should add the implements Serializable to the contract files to indicate that they are used for serialization in general and not only for IJsonSerializable. Problem there is that we should provide a SerialVersionUUID to make sure serialization works. Apart from that I added the code for serialization which automatically provides a deep copy to TrackDataOperation constructors so we don't polute TelemetryClient with the deepcopying.
Does that make sense?

[southwood]

looks good @TroubleMakerBen . Thanks!