Prevent share submission with JSON id's matching client request id's from clashing
When client submits a share to the server with an "id" in the JSON
msg that matches a "client get version" request we've asked for
previously, the share submission gets mistaken as a response for
that request. This happens when the JSON id is 10,000 due to the
default request number set for the client requests.

The fix is to make sure the JSON msg is a reply by checking that
it contains a "result" field.
Merge pull request #3 from doublec/job10000

Prevent share submission with JSON id's matching client request id's fro...