API Client refactor

[robertmclaws]

• Broke out all RPC clients into interfaces for testability.
• Renamed the internal client classes to make a bit more sense.
• Stubbed out a possible refactor of LoginClient.SetServer that would eliminate some duplicate requests.

NOTE: Still WIP.

[review-ninja]

@WallyCZ, would love your opinion on how to refactor SetServer to be able to return the first set of data w/o needing a subsequent set of requests.

[WallyCZ]

Currently it seems that we don't need any SetServer method anymore, because it tries to simulate initial communication to server, but it's different anyway. Or at least it's implementation should be changed, communication starts with repeated single (not batched) GetPlayer until reply comes (delay between request is 0.5s).

[ST-Apps]

I didn't read all the code but SetServer is needed to set the first RPC uri when launching the app.

[WallyCZ]

Ok so we need it, but we have to change it :)

[robertmclaws]

SetServer does much more than that... it's called by DoLogin() to actually complete the Login request. It's sending GetPlayer, GetHatchedEggs, GetInventory, CheckAwardedBadges, and DownloadSettings, but not actually using any of that data. If we rewrite that code, we can actually use those results to eliminate duplicate calls.

[ST-Apps]

It's shaping up nice, well done. I'd say that this is also a good chance to simplify that Settings class. We don't need both PTC and Google username/password, we only need one username, password + auth type.

[WallyCZ]

It seems that last version 0.35 started to send at init phase GetPlayer and CheckChallenge (new feature) parallel and also CheckChallenge is added to batches (so now its 5 + 1 message in batch). We need strong mechanismus which will allow to control flow messages to match with original client.

[ST-Apps]

@WallyCZ let's continue in #20