refactor(backend): [DEMO] Experimenting with v2 API in backend

[maverbiest]

Note

This is the first of two stacked PRs exploring how to build a new API inside the existing backend, as an alternative to the separate service in #7539. This PR only restructures the backend and doesn't change behaviour. #7549 (stacked on top) adds v2 group endpoints to show what adding a v2 endpoint looks like.

What this does

The backend becomes a multi-module Gradle build. It is still one Spring Boot application, one jar, one Docker image and one pod:

Module	Contents
core	Infrastructure that every API version needs: authentication, error handling, the audit log, the Keycloak adapter and the database setup with its Flyway migrations. Its test fixtures hold test helpers shared by the other modules.
v1	The current API and its implementation.
app	BackendApplication and its configuration. It combines the modules and builds backend.jar.

Why

This prepares for building a new API version next to v1:

• Its own module: the new version can depend on core but not on v1. The build enforces this, so any import from v1 is a compile error.
• No copies: code both versions need moves to core once instead of being copied, as chore(api): [DEMO – DO NOT MERGE] separate v2 API service with group management #7539 does.
• Per-module tests: each module has its own tests, e.g. ./gradlew :v1:test.

What changed

All but 21 of the changed files are pure renames. Packages are unchanged, so v1 needed no import changes. The files with real edits:

• SecurityConfig: split in two. The shared JWT/Keycloak classes moved to core/.../config/JwtAuthentication.kt; v1 keeps its path-based filter chain.
• BackendSpringConfig: the Exposed and Flyway setup moved to core/.../config/CoreSpringConfig.kt. v1's CurrentProcessingPipelineTable initialisation is now CurrentProcessingPipelineInit, which runs after core's migration.
• WebConfig: registering the user argument resolver moved to core.
• Tests:
  • The Postgres/MinIO setup, the JWT helpers (together with the test user names), PublicJwtKeyConfig, SpringBootTestWithoutDatabase and the test logging/profile config moved to core's test fixtures.
  • Each module gets a small test application class.
  • v1's test properties use paths relative to the module directory.
  • BackendApplicationTest and SwaggerUiTest moved to app, since they need the whole application.
• Build:
  • The root build.gradle holds the conventions for all modules; each module's build file only lists its dependencies.
  • Library modules align the Spring Boot BOM's Kotlin version with the Kotlin plugin, as the Boot plugin already does for app.
  • There is one lockfile per module. The app's runtime classpath is identical to before (same 242 libraries and versions).
• Paths:
  • The Dockerfile copies app/build/libs/backend.jar.
  • Migrations now live in core/src/main/resources/db/migration, and the trigger paths in schema-dump.yml and flyway-check.yml are updated.
  • bootRun runs from backend/, so the relative paths in start_dev.sh still work.
  • codespell skips the module build directories.

Notes

• Package names are unchanged, so some packages (e.g. org.loculus.backend.config) now have files in both core and v1. Renaming them could be a separate mechanical PR.
• flyway-check.yml never checked anything, even before this PR: its git diff path doesn't match from the repo root. Only its trigger path is updated here. A working check would flag this PR's moved migrations as edited.

Testing

• ./gradlew test: all 661 tests pass, with the same number of tests per class as on main.
• ./gradlew ktlintCheck is clean.
• Smoke test of the built jar against a fresh Postgres:
  • all 36 migrations ran from the core jar, and v1's startup initialisation ran after them
  • health is UP
  • the API docs are unchanged (29 paths)
• Not run locally: the Docker image build and start_dev.sh.

🤖 Generated with Claude Code