Should we permit more than 4 profiles for test suite?

PROFILELIST is deliberately limited to 4 profiles, "to force sop implementers to make hard decisions and to keep things simple".

However, for a wide-ranging interoperable test suite, some implementations might want to try to have many more types of certificate (for sop generate-key) or message (for sop encrypt). The advantage for the test suite is that implementers can try to ensure round-tripping with peers for a wide range of internally supported options.

The test suite currently doesn't limit list-profiles to four options, afaict, so this requirement isn't being enforced. Should we acknowledge it explicitly, while still retaining the advantages of forced complexity reduction where it's normally limited to 4?

One possible approach is to add some sort of extension flag like --bad-idea-profiles. sop list-profiles generate-key would be limited to 4, but sop list-profiles --bad-idea-profiles generate-key could list an arbitrary(?) number of profiles, extending the list of 4 to include all kinds of craziness. Then when invoking sop generate-key --profile=PROFILE, if PROFILE is not in the standard advertised profiles, it will fail with UNSUPPORTED_PROFILE, unless --bad-idea-profiles is also provided.

Alternately, we could just eliminate the limit of 4 entirely, but i worry that this will grow into rsa2048 and rsa3072 and rsa4096 etc, etc, exactly what we don't want OpenPGP implementations to force users to decide upon.

@teythoon, i think this change this would be primarily aimed at supporting the interop test suite. do you have any intuitions about what makes sense for us to do here?