Fix leaf client connection failing in OCSP setups

[wallyqs]

This changes ocsp handling so that leafnode remote client connections behave more similarly to how regular nats clients work, rather than mimic the bidirectional verification that happens for routes/gateways.

Resolves #3959

[philpennock]

So in discussion, the core problem here is that I made a mistake in the original specification for OCSP support, in that we conflate (1) TLS server fetching and managing its own OCSP staple for presenting to clients; with (2) the TLS client demanding a staple of the peer.

Solving this fully will require a new OCSP block keyword of peer, and probably letting the ocsp{} block be embedded in a tls{} block, as originally spec'd.

In the meantime, given the split in administrative domains between "cluster/supercluster" and "leafnodes", it makes sense to just have the peer policy match for cluster/supercluster without an explicit peer block, and turn off OCSP for leafnodes.

The trade-off which we are accepting with this PR is that the NATS server connecting as a leafnode to a hub is also losing the ability to verify the staple as presented by the hub. Fixing this will require the ability to set tls{ocsp{peer: ...}} in config. In the meantime this is a withdrawal of functionality to get to a "more likely to work" deployment. We will fix more correctly in the near-ish future.

[tbeets]

LGTM