Clippy complains about use of a mutex, suggesting we use an
`AtomicUsize`. While the same functionality _could_ be achieved using an
`AtomicUsize` and a CAS loop it makes the code harder to reason about
for little gain. Lets just quieten clippy with an allow attribute and
document why we did so.
Clippy emits warning:
warning: field assignment outside of initializer for an instance
created with Default::default()
Do as suggested by clippy and use the default init pattern.
```
let foo = Foo {
bar: ...,
Default::default()
}
```
As suggested by clippy we can use `.next()` on an iterator instead of
`nth(0)`. Although arguably no clearer, and certainly no worse, it keeps
clippy quiet and a clean lint is a good thing.
Clippy emits warning:
warning: avoid using `collect()` when not needed
As suggested by clippy just use `count` directly on the iterator instead
of `collect` followed by `len`.
While technically it's not required since there are no timelocks inside,
it's still less confusing for the end user if we allow this instead of
failing like we do currently.
The `TooManyItemsSelected` error has been removed, since it's not technically an
error but potentailly more of an "over-constraint" over a tx: for instance,
given a `thresh(3,pk(a),pk(b),older(10),older(20))` descriptor one could create
a spending tx with the `[0,1,2]` items that would only be spendable after `10`
blocks, or a tx with the `[0,2,3]` items that would be spendable after `20`.
In this case specifying more items than the threshold would create a tx with
the maximum constraint possible, in this case the `20` blocks. This is not
necessarily an error, so we should allow it without failing.
This is motivated by the feature `electrum` being part of the
`default` features of this crate. It is easy to naively enable
`esplora` and `async-interface` and forget that `electrum` is enabled
by default, running into not so obvious compile errors.
