Allow empty string as valid URL in DCR workflow

[fredericbarthelet]

Fixes #940

Motivation and Context

Allow empty URL as valid URL in DCR payload

How Has This Been Tested?

Added a specific test case for empty string

Breaking Changes

None, this actually reverts breaking change introduced by #877

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[domdomegg]

I may be wrong, please push back if so. But I think we might want to allow empty strings only on properties that are not required.

E.g. we should not allow empty string for token_endpoint. But we should allow it for op_tos_uri.

Maybe more broadly - potentially back to the issue - is should we really be accepting an empty string? Should the endpoints just not be returning anything for this property, which is already allowed by the .optional()?

[fredericbarthelet]

Thanks for your review @domdomegg. I updated my PR with a few modifications that might address some of your concern :

• keep the existing SafeUrlSchema untouched so that all URLs are checked to be valid (and deny empty strings)
• add a new OptionalSafeUrlSchema allowing optional SafeUrlSchema and empty string, but transforming the parsed value to undefined to preserve functionality down the line
• use this new Schema only on logo_uri and tos_uri in order to keep this fix for existing clients scoped to the only 2 problematic properties (and not to all optional URIs in DCR)

Maybe this new schema could be removed during next protocol version release in November in order to keep it contained within a certain time frame