Channel: Fix channel state max and add regression test

[ddustin]

Twice now that I've been aware of the channel state max wasn't updated and it slipped through without being noticed.

This PR adds an explicit test so CI will fail if the max value isn't updated.

[ksedgwic]

We could add a sentinel as the explicit last state so we wouldn't have to update the CHANNEL_STATE_MAX expr every time ...

	CHANNELD_AWAITING_SPLICE,
	DUALOPEND_OPEN_COMMIT_READY,

	/* Always keep this one last */
	CHANNEL_STATE_LIMIT
};
#define CHANNEL_STATE_MAX  (CHANNEL_STATE_LIMIT - 1)

[Lagrang3]

Nit:

I tested this.
If I add a new channel state type, eg FUTURE_CHANNEL_STATE, I must also update
many switch statements through the code or the compiler complains about a state not being handled, like for example:

./wallet/wallet.h: In function ‘channel_state_in_db’:
./wallet/wallet.h:232:9: error: enumeration value ‘FUTURE_CHANNEL_STATE’ not handled in switch [-Werror=switch]

Once all of those compiler errors are resolved the test ./common/test/run-channel_type doesn't fail.
One would need the compiler to force the user to put the new channel state value in common/test/run-channel_type.c as well
to make this test fail correctly. By removing the default case.

[madelinevibes]

This PR has been tagged for the CLN September release. Please note that they will be moved to the next milestone if not merged by August 15th.

[Lagrang3]

I tested it and now it does what it is supposed to do.

I don't have any judgement related to code conventions in Core-Lightning in this respect,
but I see it awkward that the unaware developer has to go through first a compiler
error and then a regression test fail to finally comprehend that CHANNEL_STATE_MAX
has to be updated. When all the information needed is available at compile time.
Unfortunately I cannot think of a better alternative besides the sentinel mentioned above
by @ksedgwic.