[CDEC-610] Hard Fork mechanism

[mhuesch]

Description

Implement a hard fork mechanism to transition from the legacy codebase to the new codebase.

I'm labeling with DO NOT MERGE because the debug commits must be dropped before this is merged.

Linked issue

https://iohk.myjetbrains.com/youtrack/issue/CDEC-610

Type of change

• [~] 🐞 Bug fix (non-breaking change which fixes an issue)
• [~] 🛠 New feature (non-breaking change which adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)
• [~] 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
• 🔨 New or improved tests for existing code
• [~] ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

• I have read the style guide document, and my code follows the code style of this project.
• If my code deals with exceptions, it follows the guidelines.
• I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.
• CHANGELOG entry has been added and is linked to the correct PR on GitHub.

Testing checklist

• I have added tests to cover my changes.
• All new and existing tests passed.

[erikd]

Looks great!

Don't want to merge this by accident.

[mhuesch]

I've just reproduced a successful "hard fork" on my devnet cluster by following these steps again, using the CDEC-610 branch.

This gives me fairly high confidence that this solution works, but I would be more confident if we had a secondary reproduction from a different team member. Since setting up a devnet cluster is a pain, it would be ideal if we had a method to perform the necessary rolling restart on a local cluster.

[mhuesch]

I've just dropped the extraneous DEBUG commits, and force-pushed the branch. I'm removing the DO NOT MERGE tag because this should be mergeable once CI passes (/cc @erikd).

For future reference, these are the modifications to the devnet configuration section which enable the OBFT logic. For mainnet/staging/testnets, we should alter the corresponding sections - this is just an example, not to be applied literally:

commit f90a211aba1cf2fb44215a4236104cbf317d4734
Author: Michael Hueschen <[email protected]>
Date:   Mon Oct 29 20:47:20 2018 -0400

    DEBUG [CO-610] Update config for 1.0.0, with magic Obft value

diff --git a/lib/configuration.yaml b/lib/configuration.yaml
index 3a3053f5da..8ce2be6d51 100644
--- a/lib/configuration.yaml
+++ b/lib/configuration.yaml
@@ -15073,6 +15073,7 @@ devnet: &devnet
           maxHeaderSize:      2000
           maxProposalSize:   70000 # 70KB
           maxTxSize:         65536 # 64KiB
+          unlockStakeEpoch: 9999999999999999999 # magic OBFT flag value
         protocolConstants:
           <<: *mainnet_base_protocolConstants
           protocolMagic: 170987650
@@ -15100,7 +15101,7 @@ devnet: &devnet
     applicationName: cardano-sl
     applicationVersion: 0
     lastKnownBlockVersion:
-      bvMajor: 0
+      bvMajor: 1
       bvMinor: 0
       bvAlt: 0
     systemTag: none