SIMD 0077: Programify Feature Gate Program

[buffalojoec]

This is SIMD 1/3 expected for Multi-Client Feature Gates. See #76

Goals:

• Decentralized control over queuing new runtime features
• Automatic feature activation selection based on stake weight with supporting
  software
• Decentralized governance of the mechanism itself

Resulting Architecture:

1. 👉 Feature Creation: Features can be created by anyone. Each is owned by
   an upgradeable BPF program at Feature111111111111111111111111111111111111
2. Feature Queuing: A governance process nominates features that should be
   queued for activation
3. Feature Recognition & Activation: Features are activated based on stake
   support of nodes who recognize the feature in their software version

Summary

This SIMD outlines a proposal to replace the non-existent system account at
address Feature111111111111111111111111111111111111, which is the owner of
all feature accounts, with an upgradeable BPF program.

It defines the program's initial functionality - which consists solely of the
capability to revoke pending feature activations - and an accompanying
governance system for managing upgrades of the program.

Important note: the process by which core contributors activate features
would remain completely unchanged by this SIMD.

[buffalojoec]

Hey @lheeger-jump @ripatel-fd @CriesofCarrots, I'd love to migrate conversation from Discord over to here if you guys don't mind!

The 2 main pieces we need to figure out are:

• Should this program be native or BPF?
• Should it be upgraded via multi-sig, feature gate, or both?

As discussed, it sounds like at least part of the Firedancer team is in favor of a BPF program, to spare you guys the re-implementation and testing that comes with native.

Let's discuss any details and/or concerns here to get the process rolling. Also take a look at how this SIMD (1 of 3) fits into the overall effort, including the end architecture.

[buffalojoec]

Closing in favor of #89