Fix ChannelType and Script decodings in TLVs

[dr-orlovsky]

Supersedes #27

@crisdut can you pls add your tests here and see would they pass? If yes, we will merge this one instead of #27

[codecov-commenter]

Codecov Report

Merging #30 (2d7c0f6) into master (d11a1e4) will decrease coverage by 0.1%.
The diff coverage is 0.0%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@           Coverage Diff            @@
##           master     #30     +/-   ##
========================================
- Coverage    35.1%   35.0%   -0.1%     
========================================
  Files          17      17             
  Lines        1878    1881      +3     
========================================
  Hits          659     659             
- Misses       1219    1222      +3     

Impacted Files	Coverage Δ
lnp2p/src/bolt/bolt2.rs	9.8% <0.0%> (-0.1%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[crisdut]

I tried run the tests, all tests failed.

I listed the reasons bellow:

• The TLV field shutdown_scriptpubkey causes a error when is empty. But this error is not related with this fix. I opened this issue.
• The ChannelType ::lightning_deserialize does not handle the byte array correctly (see details bellow).

[crisdut]

I think this doesn't seem right because if channel-type was not defined, FlagVec::lightning_deserialize (see here) returns FlagVec::default() (vec![0u8; 1]) instead of an empty vector.

Suggested change

	} else if flags.as_inner() == &[] as &[u8] {
	} else if flags == FlagVec::new() {

[crisdut]

This method still needs to be completed.

To clarify the problem, I wrote the test bellow:

    #[test]
    fn decode_static_remotekey_channel_type() {
        // Byte array expected by ChannelType::lightning_deserialize method
        let bytes = [0u8, 2u8, 0u8, 16u8];
        // That's Working!
        let msg = ChannelType::lightning_deserialize(&bytes);
        assert_eq!(true, msg.is_ok());


        // The byte array received by `ChannelType::lightning_deserialize` when 
        // we try decode open_channel message sent by clightning
        let bytes = [16u8, 0u8];
        // Fail!
        let msg = ChannelType::lightning_deserialize(&bytes);
        assert_eq!(true, msg.is_ok())
    }

As we can see above, the ChannelType::lightning_deserialize method receives an unexpected byte array. But I don't know if the problem is TLV decode or ChannelType itself.

[dr-orlovsky]

@crisdut I figured this thing out. If ends up with this story:

So I had to update encoding of all types which appear only in TLV not to store the length value and rely on TLV BigSize, while the other types which do not appear in TLV are encoded with 2-byte size prefix.

I published v0.9.2 with all these changes