Bug 2078690 - Migrate User REST resource to native Mojo API: user objects (get, create, update, suggest, whoami, offer_account_by_email)

[Xzzz]

Summary

Ports the user object endpoints of the legacy User REST resource to a native Mojo controller, Bugzilla::API::V1::UserObject, mirroring the pattern already used for Classification, BugUserLastVisit and Product.
Part of bug 2071909 (User), itself part of bug 2057358.

Endpoints:

• GET /rest/user
• POST /rest/user
• GET /rest/user/<id_or_name>
• PUT /rest/user/<id_or_name>
• GET /rest/user/suggest
• GET /rest/whoami
• POST /rest/user/offer_account_by_email

Changes

• Added Bugzilla/API/V1/UserObject.pm with get, create, update, suggest, whoami and offer_account_by_email. Request parameters and response format are unchanged.
• offer_account_by_email is ported here rather than in a separate UserAuth module: with login, logout and valid_login not being ported (token support is dropped in favour of API keys), it was the only endpoint left for that module. It stays login exempt, as in the legacy method.
• The controller has a type method with the same output as the legacy one, because the webservice_user_get hooks of Review, UserProfile and TagNewUsers call $webservice->type(...). The user autocomplete in the web UI depends on those hooks.
• whoami reads the X-PHABRICATOR-TOKEN header directly, since native Mojo does not populate Bugzilla->input_params
• Added qa/t/rest_user_suggest_whoami.t: neither endpoint had a test. It covers the same call as the autocomplete in js/field.js
• Added t/app-user-whoami.t: whoami with a valid, unknown and revoked API key, and with a Phabricator token (Phabricator's user.whoami is stubbed), including a disabled account
• Added permissive tests to qa/t/rest_user_get.t
• docs/en/rst/api/core/v1/user.rst: whoami validates an API key, not a token or a username and password.
• Bugzilla::WebService::User and its REST resource file are not touched here. The native routes take precedence over the ported methods. The legacy module is removed with the last User sub-task, once its remaining endpoints are migrated.

Behaviour changes

• permissive on GET /rest/user now works (bug 1787294): it called ->message on a plain string and died instead of recording a fault.
• These endpoints now authenticate like the other native ones: cookie, API key or OAuth2 bearer token. Bugzilla_login / Bugzilla_password and login tokens are no longer accepted.
• whoami still reports api_key_not_valid / api_key_revoked for an API key that is refused, as the legacy endpoint did; login_required is only returned when no key was sent.
• whoami with a Phabricator token now refuses a disabled account (account_disabled), as it does with an API key. The legacy method answered for it.
• update drops the request-level keys (include_fields, exclude_fields, Bugzilla_api_token, api_key, token, etc.) before set_all(), as in Group, so a cookie-authenticated PUT, or one passing ?api_key=, no longer fails with unknown_method.
• A null include_fields / exclude_fields in a JSON body is ignored.
• update returns id as an integer (as documented).

Test plan

• qa/t/rest_user_get.t, rest_user_create.t, rest_user_update_protected.t
• qa/t/rest_user_suggest_whoami.t (new)
• t/app-user-whoami.t (new)
• qa/t/rest_user_offer_account_by_email.t: now served by the native route
• qa/t/rest_user_login_logout.t: the endpoints still served by the legacy module are unaffected by the new routes
• User autocomplete in the web UI still shows gravatar and request counts
• GET /rest/whoami with an X-PHABRICATOR-TOKEN header

References

• Bug 2078690
• Part of bug 2071909

[dklawren]

Util.pm is in the namespace _load_api_module scans, so ->new fails and logs a warning on every startup. Update _load_api_module In Controller.pm to return early unless $module->can('setup_routes'). I do not want to move Util.pm out of V1 as a future V2 might have different code for Util.pm that behaves differently.