Add Sportarr support

[Sportarr]

This adds native support for Sportarr,
a sports event manager for TV-style sports libraries (same family of tooling
as the other apps Unpackerr polls - it grabs releases through its download
clients and imports them once extracted).

Sportarr exposes a Sonarr-v3-compatible API, so this follows the exact
pattern Whisparr established over Radarr: a [[sportarr]] config block
backed by the starr Sonarr client, with its own env prefix
(UN_SPORTARR_0_URL, ...), queue poller, validation, startup logging, and
metrics/webhook app label. Default port is 1867.

• pkg/unpackerr/sportarr.go mirrors whisparr.go ("shoehorned into
  Sonarr" the way Whisparr shoehorns into Radarr)
• config field, worker counts, poll/check calls, validator, haveQitem
  case, and startup log wired in apps.go / logs.go / start.go
• init/config/definitions.yml gained the sportarr app entry;
  examples/unpackerr.conf.example and examples/docker-compose.yml are
  regenerated from it via go generate ./... (no hand edits)

Tested: go generate ./... (idempotent), go build ./...,
go test ./pkg/..., and golangci-lint run all clean.

[davidnewhall]

If it's sonarr compatible, then support already exists. Just add it under a [[sonarr]] heading. Does this provide something else? EDIT: For what's worth, I only added whisparr because people kept joining discord asking why it wasn't working. That hasn't happened since. The same thing has never occurred with Sportarr nor Fightarr. This is probably not code that is worth maintaining since it doesn't solve any immediate problems that I can see.

[Sportarr]

If it's sonarr compatible, then support already exists. Just add it under a [[sonarr]] heading. Does this provide something else?

Sportarr is a sports event manager in the arr family. It monitors leagues and events, grabs broadcasts through the same download clients, and imports them into a season/episode library, so it has the exact queue Unpackerr polls.

It works under [[sonarr]] on the wire, yes. The reason for a named block is the same reason whisparr.go exists instead of pointing Whisparr users at [[radarr]]. Everything user-facing then says the wrong app. The startup log, the per-app worker config, and the metrics/webhook app label all report Sonarr, so dashboards and notifications tag sports grabs as a Sonarr instance the user does not actually run, and the confusion/reports begin. The named block pins that surface (right label, right default port 1867, its own env prefix) while riding your existing Sonarr client code exactly like Whisparr rides Radarr's, so cost stays near zero.

Happy to shape it differently if you'd rather, including driving Sportarr's native API instead of the Sonarr dialect. The dialect is deliberate on our side so Starr-family tools get support without carrying a custom client, but it's your call. I build Sportarr and will keep the integration updated either way. Wanted to test the waters a bit first and stay within previous territory before going full on with unfamiliar code. Really love your app and have many users who have messaged me regarding support.

[davidnewhall]

I think I'd rather solve this an entirely different way, which will probably require a config file migration. And at the same time the addition of a WebUI where these connections can be configured visually.

My idea is to just add instances as generic entities with two new variables on each, "API Type" and "Name" -- allowing you to just give the things names. If name is omitted, default to the API Type, which will be an enum of the existing Starr apps. I'll ponder on this. I could also just add a name to existing entities and avoid breaking/migrating changes. That would fix your log messages.

I'm still trying to procure a signing key, and it'll be a bit before I can release new code.

One note I'll reiterate:

The reason for a named block is the same reason whisparr.go exists instead of pointing Whisparr users at [[radarr]].

The reason for this was to suppress user complaints. I've never had a user complaint about the problem this contribution aims to solve.

[Sportarr]

I think I'd rather solve this an entirely different way, which will probably require a config file migration. And at the same time the addition of a WebUI where these connections can be configured visually.

My idea is to just add instances as generic entities with two new variables on each, "API Type" and "Name" -- allowing you to just give the things names. If name is omitted, default to the API Type, which will be an enum of the existing Starr apps. I'll ponder on this. I could also just add a name to existing entities and avoid breaking/migrating changes. That would fix your log messages.

I'm still trying to procure a signing key, and it'll be a bit before I can release new code.

One note I'll reiterate:

The reason for a named block is the same reason whisparr.go exists instead of pointing Whisparr users at [[radarr]].

The reason for this was to suppress user complaints. I've never had a user complaint about the problem this contribution aims to solve.

That shape sounds like a better solution and would cover this completely. A name on the instance is really all I need, the queue polling itself has been solid over [[sonarr]]. If you go the API Type plus Name route and want any of the grunt work done, the config migration, docs, or testing against real instances, say the word and I'll happily pick it up. No rush on our end.

Want me to close this PR in the meantime, or leave it open until you've settled on a direction?

[davidnewhall]

Just leave this open so I don't forget. It's as good as an issue. Thanks for the help!