feat: predicate validation

[MicaiahReid]

Description

This PR adds validation for predicates. The ChainhookSpecificationNetworkMap::validate(&self) method will now check each of the fields in a predicate that could have invalid data and return a string with all of the errors separated by a "\n".

I'm open to other ways of formatting the returned errors, but I think it will be nice for users to see everything that is wrong with their spec in the first use rather than being given just the first error.

Example

Here is an example result:

invalid Stacks predicate 'predicate_name' for network simnet: invalid 'then_that' value: invalid 'http_post' data: url string must be a valid Url: relative URL without a base
invalid Stacks predicate 'predicate_name' for network simnet: invalid 'then_that' value: invalid 'http_post' data: auth header must be a valid header value: failed to parse header value
invalid Stacks predicate 'predicate_name' for network simnet: invalid 'if_this' value: invalid predicate for scope 'print_event': invalid contract identifier: ParseError("Invalid principal literal: base58ck checksum 0x147e6835 does not match expected 0x9b3dfe6a")

---

Checklist

• All tests pass
• Tests added in this PR (if applicable)

[tippenein]

Looks to me like this fixes #610

[MicaiahReid]

@tippenein Not quite.

The validation function for the regex does generate the regex, but we aren't actually mutating the original struct. We'd have to add another field to store the computed regex, and we'd also have to update this validate function to mutate the predicate to store this struct.

I think where this gets tricky is that we also have to propagate this change from the ChainhookSpecification struct (where the validation happens) to the ChainhookSpecificationNetworkMap struct. When running a service, the POST /api/v1/chainhooks route takes a ChainhookSpecificationNetworkMap, validates each of its ChainhookSpecifications, then registers the network map. So for these cached values to actually get propagated through to where we're storing the predicates, we'd need to be sure everything is properly mutated.

This approach feels a bit messy to me, especially considering we'd be doing these mutations on a function called validate. I wouldn't call a validate function and assume it to have side effects like mutating the data we're validating.

---

Maybe for #610 we can add a function like pre_compute_predicate that's called closer to where we actually register the predicates. We could compute regex, the wallet descriptors on the bitcoin side, and there will likely be future predicates that could benefit from a pre computation stage.