Support configuring maxCalendarYear for Schedules beyond 2100

[gauravthadani]

Is your feature request related to a problem? Please describe.
The maxCalendarYear for Schedules is currently hardcoded to 2100.

• This prevents users from scheduling workflows or timers that need to extend beyond that year, which can be a blocker for long-running or far-future scheduling use cases.
• or are expected to update Schedules once this limit is increased

Describe the solution you'd like
Either increase the default maxCalendarYear limit, or make it configurable via DynamicConfig so that operators can adjust it without requiring a code change or redeployment.

Describe alternatives you've considered

Additional context

• this was a question from customer for payments

[zivenrokhit]

Hi! Just submitted #9396 with a proposed solution.

[dnr]

Also just copying my comment from that PR for visibility:

There's no problem with limiting actual execution of schedules to > 50 years in the future: the server will be updated and redeployed many times before that. The only real problem is that the execution limit is used in spec validation, when there's no need for that at all. That is, specs should be allowed to reference years farther in the future if they want. The matching times won't be calculated that far in the future (this is DoS protection, basically), but as soon as an updated server is deployed, they will be.

The fix should be to just stop imposing a maximum year validation on specs.

[zivenrokhit]

*Copied from PR discussion

Thanks for the feedback, I see what you are saying. I've scrapped the initial solution and relaxed the spec validation to allow for years beyond 2100, while keeping the match time DoS protection in place. I just want to highlight one possible edge case, if a user creates a schedule where the very next run isn't until after 2100, I believe the iterator will hit the DoS limit, fail to find a match, and immediately close the schedule as completed. Are we okay with this?