miniscript: introduce ValidationParams type

This introduces the ValidationParams type but does not use it anywhere.
As you can see, this is a composite of the checks in ExtParams and the
checks in miniscript::analyzable and the checks in miniscript::context.

In this commit we add a few associated constants to ValidationParams:

* MAX means "allow the maximum amount of stuff" and literally just turns
  off every single validation check. This is rarely useful by itself but
  it is frequently useful to say "do this one check" by constructing a
  ValidationParams with that check turned on and `..MAX` for everything
  else. The struct is #[non_exhaustive] so users cannot construct it
  without doing something like this.
* (There is no MIN because I can't think of a use for it.)
* CONSENSUS is MAX except enables the rules that are enforced by consensus
  across all contexts. Previously we used the term "insane" for this.
* SANE is CONSENSUS with additional policy limits and Miniscript-specific
  rules, e.g. banning duplicate public keys.

**One important change:** our CONSENSUS constant is going to replace all
usage of "insane", but CONSENSUS allows raw pkhs while "insane" did not.
It's hard for me to imagine a case where somebody would even notice this,
but I'm highlighting it because it's an intentional change to try to make
our validation rulesets match their names better. My feeling is that
"consensus" means "handle anything allowed by consensus", including
extensions like rawpkhs that exist only in rust-miniscript.

In the next commit, we will add MAX/CONSENSUS/SANE associated constants
to each context object, by starting with the global ones and then turning
on the additional rules that apply to each context.

The eventual goal is that we remove the existing analyzable/ExtParams/Ctx
stuff, drop Ctx as a type parameter on the Miniscript type, and then the
Ctx trait becomes basically a nice way to access constants.

I am keeping the term "sane" throughout these PRs, though a better term
might be "default", since the sane rules are the ones that you get if you
use the "normal" parse/decode/from_str methods. We can do this once the
dust settles a bit.

A natural question, if you are familiar with the codebase, is "why bring
in a new struct instead of just extending ExtParams". Well, I could have,
but I hate the name of the struct and the names of all the fields. And
since I'm causing a lot of API breakage I might as well take the
opportunity to improve the naming.

Author: apoelstra

src/lib.rs

@@ -124,6 +124,7 @@ pub mod plan;
 pub mod policy;
 mod primitives;
 pub mod psbt;
+mod validation;
 
 #[cfg(test)]
 mod test_utils;
@@ -147,6 +148,7 @@ use crate::prelude::*;
 pub use crate::primitives::absolute_locktime::{AbsLockTime, AbsLockTimeError};
 pub use crate::primitives::relative_locktime::{RelLockTime, RelLockTimeError};
 pub use crate::primitives::threshold::{Threshold, ThresholdError};
+pub use crate::validation::{Error as ValidationError, ValidationParams};
 
 /// Trait representing a key which can be converted to a hash type.
 pub trait MiniscriptKey: Clone + Eq + Ord + fmt::Debug + fmt::Display + hash::Hash {
@@ -492,6 +494,8 @@ pub enum Error {
     ParseThreshold(ParseThresholdError),
     /// Invalid expression tree.
     Parse(ParseError),
+    /// Validation of a script failed.
+    Validation(ValidationError),
 }
 
 #[doc(hidden)] // will be removed when we remove Error
@@ -547,6 +551,7 @@ impl fmt::Display for Error {
             Error::Threshold(ref e) => e.fmt(f),
             Error::ParseThreshold(ref e) => e.fmt(f),
             Error::Parse(ref e) => e.fmt(f),
+            Error::Validation(ref e) => e.fmt(f),
         }
     }
 }
@@ -588,6 +593,7 @@ impl std::error::Error for Error {
             Threshold(e) => Some(e),
             ParseThreshold(e) => Some(e),
             Parse(e) => Some(e),
+            Validation(e) => Some(e),
         }
     }
 }