Upgrade kotlinx-datetime to 0.7.1 and migrate Clock API

[saa-chin]

Motivation and Context

This PR resolves issue #1129 where users encounter java.lang.NoClassDefFoundError: kotlinx/datetime/Clock$System when trying to upgrade to kotlinx-datetime 0.7.x.

Problem: kotlinx-datetime 0.7.0 introduced breaking changes moving Clock from kotlinx.datetime to kotlin.time package, causing runtime failures for users upgrading kotlinx-datetime.

Solution: Migrates Koog to kotlinx-datetime 0.7.1-0.6.x-compat - eliminates NoClassDefFoundError while maintaining full backward compatibility with existing kotlinx.datetime.Clock usage.

Breaking Changes: None. Existing code continues working unchanged, with deprecation warnings guiding gradual migration to kotlin.time.Clock when ready.

Closes #1129

---

Type of the 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
• Tests improvement
• Refactoring

Checklist

• The pull request has a description of the proposed change
• I read the Contributing Guidelines before opening the pull request
• The pull request uses develop as the base branch
• Tests for the changes have been added (N/A - existing tests verify Clock.System functionality)
• All new and existing tests passed (Existing tests cover Clock usage patterns)

Additional steps for pull requests adding a new feature

• An issue describing the proposed change exists (N/A - Bug fix)
• The pull request includes a link to the issue (N/A - Bug fix)
• The change was discussed and approved in the issue (N/A - Bug fix)
• Docs have been added / updated (N/A - Internal API migration)

---

Testing Note: This change maintains the same Clock.System API surface, so existing tests that use Clock.System continue to validate the functionality. The change is purely an import migration that preserves all behavioral contracts.

For Issue Reporter (@IanArb): This PR should resolve your NoClassDefFoundError and eliminate the need for the temporary workaround mentioned by @EurigJones. After this is merged, you'll be able to use kotlinx-datetime 0.7.x with Koog without any dependency resolution strategies.

[mltheuser]

Hi, I also started working on this by accident since no one had expressed intention to pick it up in any of the related issues.

Updating to kotlinx-datetime 0.7.1-0.6.x-compat is a simple solution but rather temporary. We can already migrate to the normal kotlinx-datetime 0.7.1, with the only downside being that we need to opt-in to kotlin.time.ExperimentalTime. We could apply this to every task in build.gradle by doing:

// TODO: remove once kotlin.time becomes stable
subprojects {
    tasks.withType<KotlinCompilationTask<*>>().configureEach {
        compilerOptions {
            freeCompilerArgs.add("-opt-in=kotlin.time.ExperimentalTime")
        }
    }
}

And then when the std-lib teams makes it stable simply remove that part.

You can find the full proposed code changes here

Also left some comments on the issue

I would say, merge this PR for a quick fix and then investigate if you are willing to go for the full migration.

[saa-chin]

Hi, I also started working on this by accident since no one had expressed intention to pick it up in any of the related issues.

Updating to kotlinx-datetime 0.7.1-0.6.x-compat is a simple solution but rather temporary. We can already migrate to the normal kotlinx-datetime 0.7.1, with the only downside being that we need to opt-in to kotlin.time.ExperimentalTime. We could apply this to every task in build.gradle by doing:

// TODO: remove once kotlin.time becomes stable
subprojects {
    tasks.withType<KotlinCompilationTask<*>>().configureEach {
        compilerOptions {
            freeCompilerArgs.add("-opt-in=kotlin.time.ExperimentalTime")
        }
    }
}

And then when the std-lib teams makes it stable simply remove that part.

You can find the full proposed code changes here

Also left some comments on the issue

I would say, merge this PR for a quick fix and then investigate if you are willing to go for the full migration.

@mltheuser this was my initial commit: 3009269?notification_referrer_id=NT_kwDOAFAXS7MyMDQ3NDgyOTE4MDo1MjQ4ODQz do you prefer that I revert to that? I changed it based on @kpavlov 's comment.

[mltheuser]

Oh my bad, didn't expand the resolved review. Thats alright then.

[kpavlov]

Let's rebase and update examples (markdown files) to make knit happy

[EugeneTheDev]

Hey @saa-chin @mltheuser, just wanted to ask if any of you plan to further work on this to complete the migration, or we can pick this up and finalize it ourselves? Did you hit any blocks?

[saa-chin]

@EugeneTheDev - I have rebased, go ahead with the merge.

[EugeneTheDev]

Hey @saa-chin, I still see some errors on CI. Since you enabled "Maintainers are allowed to edit this pull request", do you mind me jumping in and fixing your PR, so that we can finally merge it?