feat: add optional Basic Auth support to Sonarr and Radarr

[zze0s]

What:

• Add optional Basic Auth support to Sonarr and Radarr

Why:
It's common to run ARRs behind reverse proxies with Basic Auth. If Profilarr and ARRs are on different servers then Profilarr needs to be able to connect to remote ARRs.

The simple and lazy solution would be to support Basic Auth in the url like http://user:pass@host.dev but that has drawbacks over separate fields that then set it as a Authorization header on the requests.

I've tested this with both Sonarr and Radarr and it works as expected.

[santiagosayshey]

Thanks for the PR :)

I left a few notes: one blocking on the password-only state and two nitpicks on the form UX.

Once the blocking bit's sorted, I think this is good to go. Cheers!

[santiagosayshey]

Blocking: Would it be possible to make password-only Basic Auth a bit more consistent? Right now it’s possible to persist the password while username is empty, but the Arr client only sends the Basic Auth header when a username exists. That leaves a hidden unused secret in the DB.

Alternatively, we could support password-only Basic Auth by dropping the username requirement in the arr client, since :password is also valid Basic Auth. Up to you!

[santiagosayshey]

Nitpick: Depending on what we decide for password-only Basic Auth, it might be nice to mirror that state in the form UX too. If password-only is treated as invalid, Save could be disabled for that state and wrapped in a Tooltip explaining that Basic Auth password requires a username.

This is a bit tricky to make that work cleanly in edit mode though- we’d probably need to expose booleans like hasBasicAuthUsername / hasBasicAuthPassword, in the same vein as hasPat / hasApiKey, since we don't send the raw values to the client.

Not a huge deal though, since the server validation would still return an error which gets surfaced as an alert.

Second Nitpick. Would it be possible to move the subtitle below a header so its consistent with the other forms? On first glance it looks like its part of the api key input. Maybe something like:

Basic Auth
subtitle
Username Password

Not sure what makes more ux sense. But either way, both are non blocking, I can work on em after its merged.