After MSRV bump: Implemented TryFrom<{u8, i32}> for Parity

[Kixunil]

No description provided.

[Kixunil]

Added commit changing cause() to source()

[Kixunil]

Rebased, @tcharding my previous PR had cause->source change so I left it in, do you want me to remove it in favor of your PR?

[tcharding]

You were first, leave yours as it is, I'll rebase mine on top of yours. I've removed the std::error::Error stuff from mine and re-worked it to include the write_err macro.

[tcharding]

ACK df081be

[sanket1729]

What was the reason that we could not have Parity::Even and Parity::Odd. Why do we have an i32 wrapping?

If the underlying FFI guarantees that the value is either 1 or 0. We should represent it in an enum. IMO, there is no need to stick to i32 just because that's the return type of C code.

[tcharding]

Did you get mixed up? We do have an enum

/// Represents the parity passed between FFI function calls.
#[derive(Copy, Clone, PartialEq, Eq, Debug, PartialOrd, Ord, Hash)]
pub enum Parity {
    /// Even parity.
    Even = 0,
    /// Odd parity.
    Odd = 1,
}

:)

[apoelstra]

ACK df081be

[apoelstra]

@sanket1729 for the purpose of encoding it in a taproot control block, which requires an integer (a u1 not an i32, but ok)

[sanket1729]

Sorry, my local tree was not updated. And I was looking at some old code :(.

We might not need the TryFrom from i32, but I have no complaints about having it either way.

[Kixunil]

@sanket1729 FYI my motivation for adding them is based on the Rust API guidelines (and I agree with that particular recommendation :))

[apoelstra]

@Kixunil for sure -- if we support conversion to/from numerics then we should definitely use TryFrom to do it. But I understood Sanket's question as being "why do we support these conversions at all?".