Adding support for HistoryProofV2

[haochenuw]

The main change in this PR is the introduction of HistoryProofV2 which improves security properties for limited history proofs. It is based upon #422, with changes to maintain backward compatibility and support unit tests for both versions of history proof.

• Added HistoryProofV2 struct and key_history_v2 and key_history_verify_v2 functions which generates and verifies HistoryProofV2.
• Extended HistoryVerificationParams to include information about the HistoryParams, to be used during the proof verification.
• Removes HistoryParams::SinceEpoch. The only way for specifying a non-default parameter now is with HistoryParams::MostRecent.
• Added a new get_marker_versions() utility function which determines the past and future version numbers to check as part of the HistoryProofV2 generation and verification
• Moved HistoryParams out from akd and into akd_core since it is also used by verification
• Added a new InvalidVersion error type
• Added tests for HistoryProofV2
• updated docs
• Bumping the version to 0.12.0-pre.1

[haochenuw]

@dillonrg -- I saw that Kevin has renamed in PR428 the MostRecent to MostRecentInsecure in HistoryParams. Since I am reusing MostRecent for history V2 as well that created a merge conflict. I have thought there are two options

1/ Rename it back to MostRecent. This is the easiest and since in this PR explicitly mark V1 of HistoryProof as deprecate, it feels like risk of misuse is small.

2/ Leave HistoryParams untouched and add a new struct HistoryParamsV2 (similarly, HistoryVerificationParamsV2). This makes the message clearer but the unit tests macros that I have added in this PR will need to be modified to pass in those structs as parameters.

Let me know what you think and I can make the changes!

cc @kevinlewi for FYI.

[haochenuw]

cc @eozturk1 @afterdusk for your thoughts on the choices above.

[kevinlewi]

@haochenuw Thanks for working on this!

I think, rather than having a key_history() and key_history_v2() interface, it might be better to instead just have one key_history() function, but add an additional parameter that allows the caller to essentially specify the version. Then, the return of the function can be an enum, something like:

pub enum KeyHistoryResult {
  V1(V1Struct),
  V2(V2Struct),
}

which can be parsed by key_history_verify() as well. That way, we also avoid having to throw everything into macros for the tests that test both versions.

Let me know what you think about the suggested change... I am hoping it will lead to a smaller change overall and simpler code.

Also, no need to push each commit to the PR, you can just force-push to erase the history and have a single commit change for the PR.

[kevinlewi]

Fantastic! Some nits in comments but overall LGTM!

[haochenuw]

All comments addressed. Closing.