allow disabling of version check

[dr-bonez]

there are some json rpc servers out there that do not return a version but are otherwise json rpc 2.0 compliant. this feature allows them to be used.

---

This change is 

[faern]

This feels like the wrong approach to me. Having even more implementations start breaking the spec will unlikely make the ecosystem better. On the other hand, we are at the same time trying to add subscriptions in at the moment, which is also not part of the real spec so..

Anyway, I still think this is the wrong approach. If this is done with a feature it forces all clients used in the same Rust binary to either use or not use the version check. This feels like something one would want to configure on each individual client.

[alexander-irbis]

Having even more implementations start breaking the spec will unlikely make the ecosystem better

Adding exceptions for the compatibility with a legacy is better for the ecosystem than creating a duplicating projects with similar functionality.

[pronebird]

I was reading a document describing differences between v1 and v2 and it basically states the following:

"jsonrpc" field added: added a version-field to the Request (and also to the Response) to resolve compatibility issues with JSON-RPC 1.0

It feels wrong to go against the spec that introduced the version field in the first place to disambiguate between the old and new protocol.

[alexander-irbis]

It feels wrong to go against the spec

I have real world services, which go against the spec. It is impossible not to go against the spec, as I depend on these services. And it just works if I comment out the check of version.

Should I make a fork of jsonrpc-client to just disable this check and to make all work? It looks somewhat pointless.

Frankly said, there are many exceptions in buggy services written by people "with curved hands". I can handle these exceptions of protocols in my code. But the version check is the ultimate feature, which prevents all communication with such services for no other reason than "to follow spec", which anyway is not followed in my cases.

[pronebird]

While seemingly easy to fix on this end, have you considered raising that issue with the services that go against the protocol?

If you are paying for the service, they must be able to assist you and fix the missing field.

I may be wrong but it’s either omission on the service’s side or they built something that resembles jsonrpc but is actually not.

[faern]

This crate is currently in a slightly shaky state. We want to upgrade to a newer hyper backend and a few other things. So very little time has been put into this crate. Basically I'm waiting for the newer futures (0.3) and async-await support before I want to invest too much time here.

But that being said. If we allow skipping the version check on replies I still don't think it should be a cargo feature that affects the entire crate. It should probably be a configure option on each client. This PR also has a merge conflict at the moment. Making it not possible to merge right now.