Remove unused Spring Boot plugin from kafkaschemaregistry (#11406)

chore(build-logic): add smoke-test plugin for nested Gradle builds

Adds a new included build `build-logic/` hosting a single subproject
`smoke-test` that exposes the `dd-trace-java.smoke-test-app` plugin.

The plugin contributes:
- `NestedGradleBuild` task type that runs a nested Gradle build via the
  Gradle Tooling API. It pins the nested Gradle version (no committed
  per-application wrappers), uses the configured Java toolchain for the
  nested daemon, forwards artifact paths from the root build as
  `-P<name>=<path>`, and redirects the nested `buildDir` via
  `-PappBuildDir=<path>` so outputs land under the outer project's build
  directory.
- `smokeTestApp` project extension with an `application { ... }` block
  that registers the `NestedGradleBuild` task, wires it into every `Test`
  task via `dependsOn` + a `jvmArgumentProvider` for the produced
  artifact's system property. Consumers can also register
  `NestedGradleBuild` directly when they need more control; the plugin
  is a no-op until `application` or a manual registration is done.
- `projectJar(name, project)` helper that forwards a sibling project's
  jar to the nested build through a resolvable `Configuration` (avoids
  `evaluationDependsOn` and the cross-project access ordering issues).

The plugin is verified with JUnit 5 unit tests (`ProjectBuilder`) and
end-to-end tests that drive the Tooling API path through the Gradle Test
Kit with a temporary Kotlin-DSL test project.

`build-logic/settings.gradle.kts` references the existing
`gradle/libs.versions.toml` catalog (mirroring `buildSrc/`) so the
plugin can use the same library coordinates as the rest of the repo.
The Gradle libs Maven repository (`https://repo.gradle.org/gradle/libs-releases`,
scoped to `org.gradle:`) is added to the root build's `pluginManagement`
and to `gradle/repositories.gradle` so the Tooling API jar resolves.

Smoke-test modules with Spring Boot plugin versions incompatible with
Gradle 9 will use this plugin in follow-up PRs instead of a committed
Gradle 8 wrapper.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

chore(build-logic): default smokeTestApp to JDK 21 daemon + Gradle 8.14.5

Set conventions on `smokeTestApp`:
- `gradleVersion` defaults to `"8.14.5"` (Gradle 8 last release; pinned because
  Spring Boot plugin pre-3.5 calls `Configuration.getUploadTaskName()`, removed
  in Gradle 9).
- `javaLauncher` defaults to a JDK 21 toolchain (the version the root build
  requires for its own Gradle 9 migration; standardising the nested daemon on
  the same JDK avoids requiring an extra toolchain on dev machines and CI
  runners).

Consumers that need a different JDK or Gradle version still override
explicitly. The inner build script is responsible for pinning the produced
bytecode level (`java { sourceCompatibility = JavaVersion.VERSION_1_8 }` or
similar) — Gradle adds `--release N` automatically when source/target differs
from the daemon JVM.

`JavaToolchainService` is now injected into the extension; this works in any
project where a `java*` (or related) plugin is applied. Smoke-test modules
already apply `gradle/java.gradle`, which applies `java`, so the convention
resolves on first read.

Public defaults exposed as `DEFAULT_NESTED_GRADLE_VERSION` and
`DEFAULT_NESTED_JAVA_VERSION` constants so the values are discoverable.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

chore(build-logic): use org.gradle.kotlin.dsl idioms in smoke-test plugin

Switch the plugin sources and unit tests over to the typed
`org.gradle.kotlin.dsl` extension functions where they replace
`::class.java` boilerplate:

- `tasks.register(name, Type::class.java) { … }` → `tasks.register<Type>(name) { … }`
- `tasks.withType(Type::class.java).configureEach { … }` → `tasks.withType<Type>().configureEach { … }`
- `extensions.create("name", Type::class.java)` → `extensions.create<Type>("name")`
- `extensions.getByType(Type::class.java)` → `extensions.getByType<Type>()`
- `extensions.findByName("name")` (followed by `isInstanceOf`) → `extensions.findByType<Type>()`
- `project.plugins.apply(Plugin::class.java)` → `project.apply<Plugin>()` (PluginAware)
- `objects.newInstance(Type::class.java)` → `objects.newInstance<Type>()`

Also drop the six `captured*` local variables in `SmokeTestAppExtension.application` —
inside `tasks.register<NestedGradleBuild>(taskName) { … }` the outer extension's
properties are now reached via `this@SmokeTestAppExtension.<prop>` directly.

No behavioural change; the 9 plugin tests still pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

chore(smoke-tests): remove unused Spring Boot plugin from kafkaschemaregistry

The Spring Boot Gradle plugin was applied but the module never produced a
bootJar/bootWar — it ships a shadow jar instead. Removing the plugin
eliminates a Gradle-9 blocker (the plugin's pre-3.5.0 versions call
`Configuration.getUploadTaskName()`, removed in Gradle 9) with no
behavioural change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Merge branch 'master' into bdu/smoke-test-pattern-b-kafkaschemaregistry

Co-authored-by: brice.dutheil <brice.dutheil@datadoghq.com>

Author: bric3

dd-smoke-tests/datastreams/kafkaschemaregistry/build.gradle

@@ -3,11 +3,9 @@ import com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar
 plugins {
   id 'com.gradleup.shadow'
   id 'java'
-  id 'org.springframework.boot' version '2.6.3'
 }
 
 apply from: "$rootDir/gradle/java.gradle"
-apply from: "$rootDir/gradle/spring-boot-plugin.gradle"
 description = 'Kafka Smoke Tests.'
 
 tasks.named("jar", Jar) {