Bug 2073282 - Add deprecated api_key=<key> query-parameter fallback to native Mojo REST auth

[Xzzz]

Summary

Adds a fallback to Bugzilla::App::Plugin::Login's Mojo login check so ?api_key=<key> query parameters are accepted the same way the legacy WebService dispatcher already accepts them, in case undiscovered callers rely on it (like k8s monitoring service actually do).

Please note that this is a deprecation-pending stopgap, not a first-class supported method (docs already warn this method is likely to be deprecated due to security concerns).

Changes

• Bugzilla::App::Plugin::Login's bugzilla.login helper: fall back to the api_key query/body parameter when the X-Bugzilla-API-Key header is absent, same precedence and validation path (revoked/sticky-IP checks, rate limiting) as the header case
• qa/t/rest_native_login.t: cover authentication via ?api_key=
• docs/en/rst/api/core/v1/general.rst: note that native Mojo REST resources also accept the deprecated api_key query parameter as a fallback

Test plan

• GET a native Mojo REST endpoint with ?api_key=<valid key> and no header -> authenticates
• Existing qa/t/rest_native_login.t cases (header, cookie + token) unaffected

References

• Bugzilla link: 2073282

[dklawren]

Thanks for jumping on this quickly.

[dklawren]

two gaps versus the legacy dispatcher this is meant to match

1. fix_credentials accepts both api_key and Bugzilla_api_key (Bugzilla/WebService/Util.pm:330 promotes the short form, and Bugzilla/Auth/Login/APIKey.pm:54 reads the long form directly). the docs warning this PR now points to also lists both. a k8s-style caller sending ?Bugzilla_api_key=<key> still gets a 401 on native resources, so the "undiscovered callers" case is only half covered

Looking through the logs, there are unfortunately some use of the Bugzilla_api_key query parameter in addition to api_key so we need to support both for now.

2. $c->param reads urlencoded/multipart body params too, not just the query string. the code comment above says "query parameter", the docs change says "query parameter", and the test only covers the query string — so the deprecated surface being reopened is larger than what is described. either use $c->req->query_params->param('api_key') to keep the stopgap minimal, or say plainly that body params are accepted as well

[dklawren]

worth adding a case where both the header and ?api_key= are sent, asserting the header wins

that precedence is security relevant — fix_credentials documents it as stopping body-injected params from overriding gateway auth headers, and it already regressed once (t/webservice-fix-credentials.t:85, bug 2035598). the || here preserves it but nothing locks it in

[dklawren]

"described in the warning below" overstates it — that warning covers Bugzilla_api_key or api_key, but only api_key works on native resources after this change. so we need to implement the long form too.