Migrate manual files to logging abstraction

[mihaimitrea-db]

🥞 Stacked PR

Use this link to review incremental changes.

• stack/logging-abstraction [Files changed]
  • stack/logging-jul [Files changed]
    • stack/logging-migration [Files changed]

---

Summary

Migrates all manually-maintained source files from direct org.slf4j imports to the SDK's logging abstraction (com.databricks.sdk.core.logging). After this PR, no hand-written file in the SDK references
SLF4J directly — all logging goes through the abstraction introduced in PR #740.

Why

PRs #740 and #741 introduced the logging abstraction and the JUL backend, but every existing call site still imported org.slf4j.Logger and org.slf4j.LoggerFactory directly. Until those imports are
rewritten, users cannot actually swap the logging backend — the abstraction would be dead code.

This PR completes the migration for all manually-maintained files. Auto-generated files are left unchanged and will be addressed separately via codegen updates.

What changed

Interface changes

None.

Behavioral changes

None. All logging calls pass through the abstraction layer, which defaults to SLF4J. Existing users see no difference.

Internal changes

• 25 files updated: each file's org.slf4j.Logger / org.slf4j.LoggerFactory imports are replaced with com.databricks.sdk.core.logging.Logger / com.databricks.sdk.core.logging.LoggerFactory. No
  other code changes — the Logger API is identical.
• Files span core, core.oauth, core.retry, core.utils, core.error, core.commons, and mixin packages.

How is this tested?

• This is a purely mechanical import swap; the Logger abstraction exposes the same debug/info/warn/error methods as org.slf4j.Logger.
• Full test suite (1140 tests) passes.