smite-ir: generate valid channel types

[morehouse]

Helps the fuzzer choose valid channel types so that deeper paths can be reached in the open_channel->accept_channel flow.

Ref: #5 (Milestone 1)

[ekzyis]

LGTM

[NishantBansal2003]

Looks fine, I only have a few nits

Also, if you go ahead with those nits, I think the enum variant names should be updated accordingly based on the comments

[NishantBansal2003]

Suggested change

	/// - `option_simple_taproot` staging (bit 180)
	/// - `option_simple_taproot_staging` (bit 180)

[morehouse]

Done.

[NishantBansal2003]

nit: would be great if we stay consistent with what the spec says:

Suggested change

	// 22 = option_anchors_zero_fee_htlc_tx
	// 40 = option_anchor_zero_fee_commitments
	// 46 = option_scid_alias
	// 50 = option_zeroconf
	// 80 = option_simple_taproot_final
	// 22 = option_anchors
	// 40 = zero_fee_commitments
	// 46 = option_scid_alias
	// 50 = option_zeroconf
	// 80 = option_simple_taproot

[morehouse]

Thanks, good catch. Done, and updated enum variants.

[NishantBansal2003]

Suggested change

	}
	#[test]
	}
	#[test]

[morehouse]

Done.

[NishantBansal2003]

One more thing -- how about adding cases where mutually exclusive channel types are set, so we can verify that implementations reject it? for eg option_anchors with option_simple_taproot

[morehouse]

One more thing -- how about adding cases where mutually exclusive channel types are set, so we can verify that implementations reject it? for eg option_anchors with option_simple_taproot

I'm not sure about this. The idea was to help the fuzzer generate correct channel types, and adding lots of invalid combinations works against that.

In order to verify rejection of incorrect types, we also need a special fuzz target that verifies the rejection occurs. If we're going to do that, we could probably hard-code all the other open_channel fields to be valid and then just use fuzz input against channel_type. That would be a much more effective targeted test.