Use diffs for proposer finalizer policy and proposer policy in block_header extension

[heifner]

[heifner]

Current finalizer_policy

   struct finalizer_policy {
      uint32_t                         generation = 0; ///< sequentially incrementing version number
      uint64_t                         threshold = 0;  ///< vote weight threshold to finalize blocks
      std::vector<finalizer_authority> finalizers;     ///< Instant Finality voter set

• Options for finalizer set
  • Order of finalizers part of consensus
    • Order by description and require unique description
    • Order by finalizer BLS key by <==> of affine_non_montgomery_le.
    • host function requires correct order
      • order in contract table for block explorers is presented in expected order
      • return -1 and don't modify finalizer_policy if not in correct order
    • host function sorts in correct order
      • easier for contract, block explorer has to know to sort to display correctly
    • diff is threshold, vector<size_t> to_remove, vector<finalizer_authority> to_add_sorted
  • Any order of finalizers allowed
    • Set in whatever order provided by host function
    • Change of order from host function sets new policy even if it is just a shuffle of existing set
    • diff is threshold, vector<size_t> to_remove, vector<tuple<size_t, finalizer_authority>> to_add
      • size_t index in to_remove is index of items to remove from set, index is before any removals
      • size_t index in to_add is index of insertion location after removals

[arhag]

We agreed to go with the option in which the protocol respects the order of finalizer authorities provided by the proposer.

We also agreed that since that algorithm for generating the diffs respects order, it is trivial to also apply this diff strategy for the producer policy as well.

Also, we want the diffs to include the expected generation / version of the new policy.