ci: Simplify module configuration and extend test coverage

[mllwchrry]

Enables all modules by default, and tests the disabling of each module separately (respecting the dependency chain). This simplifies the configuration of modules in CI and extends the test coverage.

The extended coverage is proven by exposing pre-existing issues fixed in #1837 and #1839.

[real-or-random]

Concept ACK

This simplifies the CI file and it gives us more test coverage.

cc @hebasto

I kicked CI. The failed runs all had some network/GHA issues.

[real-or-random]

I kicked CI. The failed runs all had some network/GHA issues.

Sorry, apparently I only claimed it but didn't actually press the button. Done now, let's see.

[hebasto]

Concept ACK.

Would it be possible to keep the current approach where a single module is enabled while other modules are disabled, and vice versa? This helps to ensure that they are fully independent of each other.

[real-or-random]

Concept ACK.

Would it be possible to keep the current approach where a single module is enabled while other modules are disabled, and vice versa? This helps to ensure that they are fully independent of each other.

Can you clarify? Are you suggesting doing both of the following?

1. one run for each module, where just that one module is enabled
2. one run for each module, where just that one module is disabled

If yes, then I don't think we currently do 1, or do we? (You said "keep the current approach...")

[hebasto]

Concept ACK.
Would it be possible to keep the current approach where a single module is enabled while other modules are disabled, and vice versa? This helps to ensure that they are fully independent of each other.

Can you clarify? Are you suggesting doing both of the following?

1. one run for each module, where just that one module is enabled

2. one run for each module, where just that one module is disabled

If yes, then I don't think we currently do 1, or do we? (You said "keep the current approach...")

We do this for the Recovery module. Here:

secp256k1/.github/workflows/ci.yml

Lines 98 to 99 in c1a9e4f

	- env_vars: { WIDEMUL: 'int64', RECOVERY: 'yes' }
	- env_vars: { WIDEMUL: 'int64', ECDH: 'yes', EXTRAKEYS: 'yes', SCHNORRSIG: 'yes', MUSIG: 'yes', ELLSWIFT: 'yes' }

Here (almost):

secp256k1/.github/workflows/ci.yml

Lines 102 to 103 in c1a9e4f

	- env_vars: { WIDEMUL: 'int128', RECOVERY: 'yes', EXTRAKEYS: 'yes', SCHNORRSIG: 'yes', MUSIG: 'yes', ELLSWIFT: 'yes' }
	- env_vars: { WIDEMUL: 'int128', ECDH: 'yes', EXTRAKEYS: 'yes', SCHNORRSIG: 'yes', MUSIG: 'yes' }

And here:

secp256k1/.github/workflows/ci.yml

Lines 461 to 462 in c1a9e4f

	- { WIDEMUL: 'int128', ECDH: 'yes', EXTRAKEYS: 'yes', SCHNORRSIG: 'yes', MUSIG: 'yes', ELLSWIFT: 'yes' }
	- { WIDEMUL: 'int128', RECOVERY: 'yes' }

[mllwchrry]

Would it be possible to keep the current approach where a single module is enabled while other modules are disabled, and vice versa? This helps to ensure that they are fully independent of each other.

Thanks for the feedback! I wonder what's the failure scenario that the "disable one" approach misses? If A has an unguarded dependency on B, { B: 'no' } catches it.
Solo enable entries would add 16 runs. I think that's ok, but first I want to understand explicitly how it expands the coverage.