Punycode Fix and Optional Cohort Number

[sciros]

This pull request introduces several enhancements and bug fixes across the codebase, most notably improving domain name handling in DomainEncoder, adding support for selecting a specific cohort for single-attempt MPIC orchestration, and expanding related test coverage. It also includes some refactoring, such as relocating exceptions and updating error messages.

Domain name handling improvements:

• Improved DomainEncoder.prepare_target_for_lookup to correctly detect and handle already punycode-encoded domains (including inner labels), ensuring they are not double-encoded and raising clear errors for malformed domains. Added stricter validation for wildcards and malformed input.
• Expanded unit tests for DomainEncoder to cover more edge cases, including already-encoded domains, wildcards, inner punycode labels, and malformed domains. [1] [2]

MPIC orchestration enhancements:

• Added support for specifying a cohort_for_single_attempt parameter in MpicRequestOrchestrationParameters, allowing users to select a specific cohort for a single orchestration attempt. The coordinator now validates this parameter and raises a new CohortSelectionException if the requested cohort is invalid. [1] [2] [3] [4] [5] [6] [7]
• Added and updated unit tests to verify correct handling of the new cohort selection feature, including validation and error scenarios.

Refactoring and error handling:

• Moved CohortCreationException to mpic_request_errors.py and introduced a new CohortSelectionException for invalid cohort selection. Updated all imports and error messages accordingly. [1] [2] [3] [4] [5] [6] [7]
• Updated version to 6.2.0 in __about__.py.

Test improvements:

• Refactored DCV checker tests to combine and clarify test cases for malformed and well-formed IP addresses, ensuring only valid formats allow issuance. [1] [2]

[birgelee]

This looks good, thanks for the work.

[birgelee]

I'm not going to block on this, but somehow my C programing mindset gets a little scared when I see numbered format tokens in string literals particularly when the format string is declared separately from the format commend. I think this is all good but if one of these strings was rewritten to have fewer or more format tokens, would that cause an error (at least its not going to just buffer overflow like it would in C).

[sciros]

It won't cause issues like in C and thankfully there's unit tests that exercise the error code but it's not as elegant as maybe some other approach could be.
Anthropic Claude's take:

Key difference from C: Unlike C's format string vulnerabilities, Python's string formatting is type-safe and memory-safe. There's no buffer overflow risk, and mismatches produce clear runtime errors rather than undefined behavior or security issues.
Practical considerations:

• The error would be caught immediately when that code path executes (unlike silent C corruption)
• Unit tests covering these error cases would catch mismatches
• f-strings (f"Response status {status}") would make this mismatch impossible since variables are directly embedded, though they'd require the values at definition time rather than later formatting

The pattern here (constants with deferred formatting) is reasonable for error definitions. The main risk is maintenance errors that tests should catch.