Light client does not trust block 1

[greg-szabo]

When a light_node starts without previous information about the blockchain, it starts bisecting at height 1. But the is_within_trust_period doesn't distinguish this and if a blockchain was started days ago, it will throw an Expired error and quit. (The default trusting_period is 600 minutes, but the first header can have any past date on it.) I'm guessing the is_within_trust_period function should not check the trusting_period at block height 1 while still checking that the header is not after now. Alternatively, if the trusting_period expired, we should catch that and start catching up from block height 1, instead of stopping.

Further troubleshooting revealed the following: I put in a check if we're trying to catch up from height 1 and didn't throw an exception. The application started but I got bisection messages always starting at height 1. Example:

attempting bisection from height 1 to height 2920
Succeeded bisecting!
attempting bisection from height 1 to height 2920
Succeeded bisecting!
attempting bisection from height 1 to height 2920
Succeeded bisecting!
attempting bisection from height 1 to height 2921
Succeeded bisecting!
attempting bisection from height 1 to height 2921
Succeeded bisecting!

I'm not sure how it should work, but this seems like there are other issues in the code.

[ebuchman]

If the blockchain was started too far in the past, and is_within_trust_period is false, then the light client should fail - that's the correct behaviour.

For testing purposes, we need to make sure that the blockchain's genesis time is recent enough so that we can run the light client from the first block.

We can also consider test that don't require this, but then the light client won't be able to sync from the first height, it will have to use a "subjective" initialization from some higher height.

[ebuchman]

Can we close this? Syncing from genesis appears to be already impossible because we don't have a good way to populate a TrustedState with the genesis state yet anyways, and we can track that in #201

[ebuchman]

Closing for #201