fix: replace loop timeout by max match date

[sheerlox]

Description

This change is inspired by cronie's crond.
It replaces the 5 seconds timeout in the _getNextDateFrom while loop by a maximum date in the future (8 years).

Related Issue

Fixes #467.
Closes #499.

Motivation and Context

In environments with limited resources (CPU/memory), it may take more than 5 seconds to find the next date. This throws an error (see #467), while it should only take the time it needs and find the occurence.

How Has This Been Tested?

Using the systemd-run command, I've been able to compare the behavior of test runs between the main branch and this version and to confirm that these changes have all tests passing correctly in a low resources environment.

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)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• If my change introduces a breaking change, I have added a ! after the type/scope in the title (see the Conventional Commits standard).

This issue was initially discussed on Discord.

[intcreator]

for posterity: @sheerlox and I had a conversation about this on Discord. we decided that it's ok to take a long time to find the next cron execution time since that could be up to 8 years away. if it takes more than a few seconds to find the next execution time then the execution time is almost certainly farther away than how long it takes to find it (for example if at 8:00:00 pm you look for the next execution time and it takes you until 8:00:08 it's probably because the next execution time is hours, days, months, or years away and it won't cause errors to take so long finding it).

we feel good closing #467 because this will remove the 5 second timeout (which we decided isn't needed) and also #499 which would have added a parameter to bypass the 5 second timeout.

the ~8 year check should in theory never trigger but if it does it will alert us that something is wrong in the code since no cron execution time should ever be more than 8 years away by definition from the spec

[ncb000gt]

🎉 This PR is included in version 2.4.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[ncb000gt]

🎉 This PR is included in version 3.0.0-beta.2 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀