Add test for proposervm BuildBlock after bootstrapping

[StephenButtolph]

Why this should be merged

1. https://github.com/ava-labs/avalanchego/blob/master/vms/proposervm/scheduler/scheduler.go#L52. The initial build block time is specified when starting the scheduler.
2. https://github.com/ava-labs/avalanchego/blob/master/vms/proposervm/vm.go#L181. The initial build block time is just passed in as time.Now() - so the scheduler is initialized to allow BuildBlock requests from the inner vm.
3. https://github.com/ava-labs/avalanchego/blob/master/snow/engine/snowman/transitive.go#L500. When the node is transitioning into normal operations, we initialize the preference.
   a. https://github.com/ava-labs/avalanchego/blob/master/snow/engine/snowman/transitive.go#L513. Notice that this is before SetState is called, so we wouldn't expect the inner VM to have requested block building yet.
4. https://github.com/ava-labs/avalanchego/blob/master/vms/proposervm/vm.go#L340-L343. It was known that in this situation the P-chain may have been behind this chain due to blocks being force accepted during bootstrapping.
   a. What I had forgotten was that the scheduler was actually initialized to allow the BuildBlock calls through from the inner VM (by initially passing in time.Now()).
5. At this point the flow feels fairly clear to get to the error:
   a. https://github.com/ava-labs/avalanchego/blob/master/vms/proposervm/vm.go#L279
   b. https://github.com/ava-labs/avalanchego/blob/master/vms/proposervm/post_fork_block.go#L148
   c. https://github.com/ava-labs/avalanchego/blob/master/vms/proposervm/block.go#L203
   d. https://github.com/ava-labs/avalanchego/blob/master/vms/proposervm/block.go#L413

Now, I'm not exactly sure how we want to handle this... Normally we'd re-add the the PendingTxs notification to the inner VM's toEngine channel... But in this case that would just be a passthrough to the proposer VM's toEngine channel... So we'd just spin calling BuildBlock.

Alternatively, rather than passing in time.Now() to the scheduler initialization, we could pass in something like MaxTime. But if SetPreference isn't isn't called after the P-chain advances... then we'd never build the block. We could just pick some random time in the future... But that seems arbitrary and fragile.

Perhaps we should add some method to the validators.State interface that blocks until the requested height is accepted (or just periodically poll the existing functions) so that we could then manually re-calculate the scheduler window at that time.

How this works

How this was tested

[github-actions]

This PR has become stale because it has been open for 30 days with no activity. Adding the lifecycle/frozen label will cause this PR to ignore lifecycle events.