Merge insecureGRPC and insecureJSONRPC

[directionless]

Create insecureTransport as a unification of insecureGRPC and insecureJSONRPC.

These options are meaningless to split, and this way has less to get tangled up with.

[groob]

Have you considered not passing a second "insecure" option to NewJSONRPC? The reason gRPC has two is because it's possible to use tls(with a insecure cert) or drop tls entirely.

Currently for JSONRPC you're passing two "insecure" flags. one manages TLS. What does the other do?

[directionless]

For good or ill, the jsonrpc transport intends to follow the same model. You can connect to http or https, and you can verify or not verify the certs.

I've certainly considered merging the two options, or renaming insecure to no-verify-tls, but it felt like it might have wider impact.

[blaedj]

This looks good to me, but I think we should either mention it explicitly in a change log or just check & error if the insecure_grpc flag is passed.

[directionless]

@blaedj Normal flag parsing will spit an error back for unknown flags. I don't want to extend that.

[blaedj]

Ah thats true,