Panic on blob deserialization

[mzabaluev]

The .into() call in try_verify can panic if the signature field inside the blob is not the correct length. This occurs before signature verification, so anyone can post such a blob on Celestia and cause movement nodes to panic.
Here’s a small unit test demonstrating the panic:

	#[test]
	fn poc_verify_can_panic() -> Result<(), anyhow::Error> {
		let s = InnerSignedBlobV1 {
			data: InnerSignedBlobV1Data::try_new(vec![1, 2, 3], 123).unwrap(),
			signature: vec![],
			signer: vec![
				2, 130, 130, 130, 130, 130, 130, 130, 82, 130, 130, 130, 130, 255, 255, 130, 130,
				130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130, 130,
			],
			id: Id(vec![1, 2, 3, 4]),
		};

		s.try_verify::<k256::Secp256k1>()?;

		Ok(())
	}

[mzabaluev]

The ecdsa crate uses an old version of generic-array, where the From<&[u8]> impl is panicky where by righs it should not exist: the TryFrom trait is the one for potentially fallible conversions. Unfortunately, the authors did't seem to believe in fallible conversions until later versions. Thanks for spotting this; such subtle ergonomic faults somewhat negate the value of using generic-array in rust-crypto.

[mzabaluev]

Fixed in commit dd3757b of #937