Support bisecting headers in updateClient if too much change.

[ethanfrey]

If updateClient fails as there was > 1/3 validator change since the last trusted header, we need to submit a few steps that can each be proven.

Detect this particular error from the sdk (using error code?) and handle it different. This can be done in 3 parts

(1) We need a test case that fails. It requires a multi-node setup and an account with many staking tokens throwing around their weight.
(2) We can try a naive bisect algorithm and let the server do the verification (expensive), but most importantly ensure the test passes. Handling the server errors properly is important here, as we may always get such errors if there is a timing issue (changes between a pre-query and the submission)
(3) We can check the % change in validator sets on the client side and calculate a path of the needed headers before blindly submitting very bisect header needed.