Bug 2061441 - Migrate Classification REST resource to native Mojo API

[Xzzz]

Summary

Ports Bugzilla::WebService::Classification's get method into a native Bugzilla::API::V1::Classification Mojo controller, mirroring the pattern already used for Component/Teams/Reminders/Configuration/User/etc.

This is the first of a set of child bugs migrating REST resources to native Mojo API, see 2057358 for details.

Changes

• Add Bugzilla/API/V1/Classification.pm: GET /rest/classification/:id_or_name, same permission logic (useclassification param / editclassifications group) and JSON response shape as the legacy endpoint
• Delete Bugzilla/WebService/Classification.pm and Bugzilla/WebService/Server/REST/Resources/Classification.pm
• Remove the Classification entry from WS_DISPATCH in Bugzilla/WebService/Constants.pm and drop the corresponding use line in Bugzilla/WebService/Server/REST.pm, since both REST.pm::preload and _find_resource iterate that dispatch table and would otherwise try to load a now-deleted module

Test plan

• Verified against a local docker instance:
  • GET /rest/classification/1 and GET /rest/classification/Unclassified (by id and by name) both return the expected classifications JSON
  • GET /rest/classification/99999 and .../NoSuchClass both throw the correct object_does_not_exist error
  • Confirmed unmatched paths still fall through correctly to the legacy rest.cgi compat route
• Ran the sanity/bmo/webservices/selenium1-4 test suites clean

References

• Bugzilla link: 2061441
• Part of 2057358

[dklawren]

Overall the port matches the established Bugzilla::API::V1::* pattern, and the cleanup of WS_DISPATCH plus the two deleted modules checks out. I verified there is no jsonrpc.cgi in the tree, so WS_DISPATCH is only consumed by REST.pm::preload and _find_resource, and
there are no dangling references to either deleted module. Route ordering also puts API.pm ahead of the rest.cgi fallback, so the new route wins.

Four things I would like addressed before this lands. The first three are contract regressions against the endpoint this replaces.

1. Route placeholder narrows what names match

Bugzilla/API/V1/Classification.pm:20

:id_or_name is a standard Mojolicious placeholder, so it matches [^/.]+. The legacy resource regex was [^/]+. A classification name containing a dot used to resolve and now falls through to the legacy rest.cgi route, which no longer knows this resource, so the client gets a confusing 404 instead of data.

$class_routes->get('/#id_or_name')->to('V1::Classification#get');

2. id and sort_key lose their numeric JSON type

Bugzilla/API/V1/Classification.pm:58

The legacy code ran these through $self->type('int', ...), which does a literal int($value) (Bugzilla/WebService/Server/JSONRPC.pm:211), guaranteeing "id": 1. Now the raw DBI value goes straight to Mojo::JSON, so a value read from MySQL serializes as "id": "1".

It gets worse than a flat change: Bugzilla::Classification is IS_CONFIG => 1, so it is memcached, and a cache hit round-trips through JSON and comes back as a real number. The type flips depending on cache state, which is harder to catch than a consistent break.

docs/en/rst/api/core/v1/classification.rst:62 documents both as int. The same applies to the product id in _product_to_hash. Forcing numeric context (0 + $classification->id) is enough.

3. include_fields and exclude_fields are no longer honored

Bugzilla/API/V1/Classification.pm:46

The legacy method wrapped both hashes in filter $params, and its POD documented these as accepted. A client calling ?include_fields=name now gets the full object back. Either support it here or call the drop out explicitly in the PR description and the docs.