Improve consensus handling of clients with skewed clocks
It is my understanding that we aim to support clients with skewed clocks.
I open this ticket for a few suggestions on improving consensus handling by clock skewed clients. It might be worth opening more tickets for better support of clock skewed clients in other parts of the protocol as well. The ideas of this ticket came up while working on prop224.
a) We might want to start accepting consensuses whose valid_after date is slightly in the future (maybe an hour or two max). We are already flexible towards old consensuses (we accept consenuses up to 24 hours old), so maybe we should be flexible in the other direction as well. This should help with slightly backwards-skewed clients.
Security wise, handling future consensuses is in some way safer than handling old consensuses (since these are replayable).
b) We might want to improve our logging when receiving ultra old consensuses. Right now we fail bootstrap silently if we receive a consensus with a valid_until older than 24 hours. This affects clients with clocks skewed forward, and they never learn what the problem is.