Light GRANDPA import handler

[svyatonik]

closes #269

I'm opening this PR to share the ideas && to make sure I'm on the right track. So the general idea is:

1. we do not pause syncing when see a block with consensus-related changes (which is just DigestItem::AuthoritiesChange now). This differs from original description of Light-client Authority Set Handoffs #269 and what has been discussed in GRANDPA finality proof draft #1268. But since full clients do not pause sync, I'm not sure - why light clients should (that's what bothering me). So light block importer only tries to get finalization of such blocks ASAP;
2. getting finalization = checking justification. To check justification, we need to know GRANDPA authorities set. One possible option is to use existing finality proof every time, but I think I've found a better way:
   2.1) assuming that every change of this set if accompanied with justification;
   2.2) when seeing a justification we could assume that it is created with previous set;
   2.3) if check-with-previous-set fails, we're fetching GRANDPA authorities set from the remote full node;
   2.4) if recheck-with-new-set works, then we're finalizing the block + storing new set + new set_id (which is increased by one on every change) locally

This should work when justifications are already created (i.e. when we're syncing from the scratch). But there's a case when this strategy will fail:

1. B1 which enacts new GRANDPA authorities set is imported on FULL client without justification (let's say it changes set_id from 10 to 11);
2. FULL announces this block to LIGHT && light imports the block without finalization (set_id is still 10 on light);
3. FULL creates justification J1 for B1, but it doesn't reach LIGHT yet;
4. B2 which updates set_id from 11 to 12 is imported by FULL && justification J2 is created;
5. light client tries to import B2+J2 && import fails, because it has missed 10 -> 11 change of set_id.

That's where I suppose finality proof could help (if changed a bit). So that new finality proof (which will work in both optimistic + pessimistic cases) will be:
REQUEST: prove finalization of BEST_BLOCK given that our best finalized is BEST_FINALIZED
RESPONSE:
    assume that we have best justification for BEST_BLOCK+2
    if GRANDPA set has NOT been changed in [BEST_FINALIZED; BEST_BLOCK+2]:
        we only need to respond with justification for BEST_BLOCK+2
    if GRANDPA set has been changed in that range:
        we need to respond with justifications for all intermediate changes
        + proof-of-execution for GRANDPA::authorities for all intermediate changes
        + justification for BEST_BLOCK+2

The goal of this PR is to have:

1. light client that is able to import GRANDPA justifications;
2. light client that is able to synchronize with minimal # of calls into runtime (i.e. only when proofs are required):
   2.1) I've reenabled authorities cache for that => when Aura verifier requests authorities, they're fetched from the cache;
   2.2) I've added extraction of new_authorities into Aura verifier => light client is notified when the set changes && the cache is updated accordingly.

cc @rphmeier

[svyatonik]

depends on #1603 - can't make tests with current test_client implementation

[rphmeier]

@svyatonik can we ice this until the offline-fallback is in? Mostly because I want to make sure that some things are handled correctly for light clients (that they are actually halting in case of a forced change.)

[svyatonik]

@rphmeier Sure! Depends on #1619

[pepyakin]

@svyatonik this requires conflict fixes.

@rphmeier / @andresilva can you have another look at this?

[gavofyork]

@svyatonik more conflicts to be resolved...

[svyatonik]

testing blocked by #2499 + I have found some verification issue - the fix will be here

[andresilva]

Could you merge master to include #2499 and fix conflicts?

[svyatonik]

@andresilva Will do, but there's (unfortunately) another major issue - I'm currently preparing separate PR for that && will leave this PR as gotissues until we will have that PR merged in.

[tomaka]

This conflicts quite heavily with my WIP for a networking cleanup. I'm going to wait for this to be in to continue.

[svyatonik]

@andresilva @tomaka Sorry for delay - I've merged with master (had the same "too many files open problem" issue - we need to figure out the reason). This is ready for review again, but if you want to do a real testing, you should also cherry-pick commits from #2512 (the Aura part was broken, the GRANDPA looks OK to me).

[gavofyork]

going to need resolving...