Consider correcting Bank::slots_per_year drift

[mvines]

Similarly to #9874, inflation and rent calculations are based on a theoretical number of slots per year:

solana/runtime/src/bank.rs

Lines 939 to 943 in 5e89bd8

	self.slots_per_year = years_as_slots(
	1.0,
	&genesis_config.poh_config.target_tick_duration,
	self.ticks_per_slot,
	);

At the time of this issue, the actual slots_per_year rate appears to be about 1 week ahead of the theoretical, meaning that inflation will taper faster than expected and rent will become due sooner:

$ solana block-time
Block: 11525626
Date: 2020-05-17T17:07:27Z (UnixTimestamp: 1589735247)

$ solana cluster-date 
Block: 11525640
Date: 2020-05-08T23:06:38Z (UnixTimestamp: 1588979198)

Let's decide if this even is a problem first.

[mvines]

Let's decide if this even is a problem first.

Yep it's a problem. At every Epoch we probably should adjust solana cluster-date towards solana block-time, but it must not go backwards.

[garious]

Per conversation with @mvines, we can change Clock::unix_timestamp from PoH time to block time, but only update when block time increases. We can make the transition on Mainnet Beta now because PoH time is currently behind block time.

[CriesofCarrots]

Update on this: solana cluster-date is now corrected toward solana block-time, with various caveats (time cannot got backward, changes are bounded to 25% of the poh estimate since the start of the slot).

However, it is not certain how the slots-per-year calculation ought to be corrected. Presumably we want the annualized interest rate to be correct, but we need to consider how much and how often we want the rate to drift (or correct itself). Since inflation is only just about to begin on mainnet-beta, it seems like we will want to observe and collect data for a while to make these determinations.