Add tests for the Debug and activation Vecs

[ryoqun]

Problem

• We could be in bad scheduling when specifying epochs to activate native programs
• Debug for Programs and MessageProcessor isn't tested. (The Debug impls aren't derived; it's manually written due to rustc bug/limitation around function pointer).

Summary of Changes

• Extend sanity checks for the scheduling data of programs by epoch. Let's make scheduling less error-prone.
• Add very simple tests for Debug.

Context

follow up of #11736

[ryoqun]

fyi: Part of my patches were already got in #11916 ;)

[codecov]

Codecov Report

Merging #11926 into master will increase coverage by 0.0%.
The diff coverage is 83.9%.

@@           Coverage Diff           @@
##           master   #11926   +/-   ##
=======================================
  Coverage    82.1%    82.2%           
=======================================
  Files         332      332           
  Lines       78095    78142   +47     
=======================================
+ Hits        64153    64235   +82     
+ Misses      13942    13907   -35     

[mvines]

This is sneaky. For real safety here I think we need a compile-time check to inform us when additional restrictions are being added here so we can gate them. For example if there's a new sysvar or native_loader added, during the 33%-66% upgrade window, anybody can kill the cluster with a simple solana transfer.

[jackcmay]

Would also be nice to reserve an upgrade path for our known ids like BPFLoader2111111111.... BPFLoader31111111....., etc...

[ryoqun]

oops, odd. This is intended to be pushed to #11928...

[ryoqun]

@mvines

For real safety here I think we need a compile-time check to inform us when additional restrictions are being added here so we can gate them.

This is interesting and timely. :) Well, since Rust 1.46, we can do this to some extent thanks to const fn improvements: https://blog.rust-lang.org/2020/08/27/Rust-1.46.0.html#const-fn-improvements. Namely, we can digest the ast tokens at the compile-time and create sha256 and compare it against annootated frozen_code(digest = "fooBarbase58") as an auto-generated test just like frozen_abi(...).

For example if there's a new sysvar or native_loader added, during the 33%-66% upgrade window, anybody can kill the cluster with a simple solana transfer.

Well, the attack isn't involved with SystemInstruction::Transfer. This is related to SystemInstruction::Assign. Anyway, it's very easy to kill cluster without gating... I'll gate it.

[ryoqun]

Would also be nice to reserve an upgrade path for our known ids like BPFLoader2111111111.... BPFLoader31111111....., etc...

@jackcmay gotcha!

[ryoqun]

silly me...:

$ git add --patch
...
==> 2020-08-31 16:47:29.316707928|0
$ git commit -m "Add tests for the Debug and activation Vecs and " -a
[for-small-patches cc2169a] Add tests for the Debug and activation Vecs and
5 files changed, 99 insertions(+), 13 deletions(-)
==> 2020-08-31 16:49:29.752882042|0

[ryoqun]

Well, we must require the uniqueness separately both for name and id, not for the tuple of (name, id).

[ryoqun]

@mvines @jackcmay this is ready for review again! I think this is strictly non-functional change now. Sorry for sneaky changes...