[czifrushanna]

Work in progress - opening early for feedback on the shape of the framework,
not as a merge-ready change.

Adds an optimizer adapter framework modelled on the existing pluggable scanner
adapters: Harbor hands an artifact to an external service and gets back an
optimized Dockerfile, recovered from the image's BuildKit provenance and informed
by its Trivy scan report. Harbor takes on no LLM dependency - it only speaks the
adapter contract.

• optimizer_registration + versioned adapter REST contract, mirroring
  scanner_registration / pkg/scan/rest/v1 (migrations 0191–0193)
• Async OPTIMIZE_ARTIFACT job using a single-use pull-scoped robot account
• /optimizers registration CRUD API + a Dockerfile tab on the artifact view
  and an Optimizers tab under Interrogation Services

Why a separate framework, for now

pkg/optimizer deliberately mirrors the scanner adapter framework rather than
extending it, and the optimizer lives in its own registration table and packages.
The overlap is real and I'm not hiding it - the registration DAO is three lines
from identical to the scanner's, and the manager is ~80% the same.

Keeping them separate keeps this PR purely additive: nothing on the scan path
changes, so an experimental feature can't destabilise a shipped one. Consolidating
into a shared adapter/registration package is already proposed in goharbor/community#285, and could be the next step after one question is decided: both registrations are beego ORM
models with a fixed TableName(), so a single shared struct can't back two tables -
the manager, controller and REST transport generalise cleanly, the DAO layer needs a
pattern this codebase doesn't use yet.

The adapter service itself is external by design, for the same reason Trivy is:
Harbor stays free of any LLM or model dependency and only speaks the REST contract.

Trying it out

The reference adapter is sleeko, a standalone Go service:
https://github.com/czifrushanna/sleeko (README covers running it
against a Harbor built from this version). It is deliberately minimal for now - a
single LLM API call per artifact; I am working on optimizing the optimization workflow itself.

Still to do

Adapter contract v1 isn't frozen yet, there are no e2e tests (verification has
been manual against a live cluster), and docs aren't written.

Related to goharbor/community#285 and goharbor/community#282

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.