As we just did for `absolute::LockTime` add a method `is_implied_by` and
deprecate `is_satisfied_by_lock`.
Reasoning: it is odd to think of a lock satisfying another lock but it
is clear to see that satisfaction of one lock can imply satisfaction of
another.
When filtering it is necessary to check two lock times against each
other, we currently provide a patter for doing so in the docs but we can
do better.
It was observed that satisfaction of a lock time 'implies' satisfaction
of another lock time if the lock times are the same unit and one locks
value is less than the others - this is exactly the code pattern we
suggest for filtering.
Add a method on `absolute::LockTime` for checking a lock against another
lock, add rustdoc comment explaining the methods function in filtering
prospective lock time values (how we use it in `rust-miniscript`).
Currently in one of the rustdoc examples showing lock satisfaction we
use two locks with the same value, this obfuscates which lock is doing
the satisfying and which lock is being satisfied.
Increment the value in one of the locks so it is obvious which lock is
which.
Add a new crate `bitcoin-internals` to be used for internal code needed
by multiple soon-to-be-created crates.
Add the `write_err` macro to `bitcoin-internals`, nothing else.
This patch uses a `path` dependency which means `rust-bitcoin` cannot be
released in its current state, will need to be changed once we release
the `bitcoin-internals` crate on `crates.io`.
Create a directory `bitcoin` and move into it the following as is with
no code changes:
- src
- Cargo.toml
- contrib
- test_data
- examples
Then do:
- Add a workspace to the repository root directory.
- Add the newly created `bitcoin` crate to the workspace.
- Exclude `fuzz` and `embedded` crates from the workspace.
- Add a contrib/test.sh script that runs contrib/test.sh in each
sub-crate
- Fix the bitcoin/contrib/test.sh script
Tobin C. Harding