feat: add HTTP QUERY method support

[memleakd]

Description

This PR proposes adding support for the HTTP QUERY method defined by RFC 10008.

QUERY fills a long-standing gap between GET and POST.

GET is the right semantic fit for read-only requests, but it pushes all query data into the URL. That works for simple filters, but it becomes awkward for advanced search screens, report previews, analytics queries, GraphQL-style reads, JSON-RPC queries, or audit-log filters with nested conditions.

POST can carry that data in the body, but it no longer clearly communicates that the request is safe and read-only.

QUERY gives applications a better option: a safe and idempotent request with query content in the request body. In CodeIgniter this can be expressed naturally with a route like:

$routes->query('products/search', 'Products::search');

This is not just a CodeIgniter-specific idea. The web ecosystem has already started moving in this direction, with support merged or being discussed in nginx, Symfony, Laravel, Rails, Spring Framework, Node.js, and other projects.

This PR wires QUERY into the framework areas where CodeIgniter already exposes HTTP methods:

• CodeIgniter\HTTP\Method
• route definitions via $routes->query(...)
• route matching via match(['QUERY'], ...)
• route command output
• Feature tests via $this->query(...)
• CURLRequest::query(...)
• validation and Form Request input source selection

For input handling, QUERY follows the same raw-body path as PUT, PATCH, and DELETE. JSON requests continue to use the existing JSON handling based on Content-Type.

This PR is intentionally conservative. It teaches CodeIgniter how to recognize, route, test, and send QUERY requests, but it does not add special cache handling, Accept-Query support, or global Content-Type enforcement. Applications should still decide which query content types they accept and validate that in the controller or request layer.

Tests cover routing, route command output, feature testing, CURLRequest, validation, Form Requests, raw input handling, and CSRF behavior.

References

• RFC 10008: https://www.rfc-editor.org/rfc/rfc10008.html
• IANA HTTP Method Registry: https://www.iana.org/assignments/http-methods/http-methods.xhtml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[datamweb]

Overall, I like this PR.

[michalsn]

I think two things should be addressed:

1. Page cache must not cache QUERY using the current method+URI key. QUERY request content is part of the request, so cachePage() can serve one request body response to another body on the same URI.

2. The behavior change for existing $routes->add() routes should be documented.

[memleakd]

Thanks for the review @michalsn.

PageCache now skips QUERY requests, the $routes->add() behavior change is documented, and the CURLRequest::query() docs clarify the difference from the query request option.

[michalsn]

After reading RFC 10008 more closely, I have two thoughts, which are candidates for follow-up PRs.

Servers MUST fail the request if the Content-Type request field ([HTTP], Section 8.3) is missing or is inconsistent with the request content.

The user guide currently leaves this to the developer, which is acceptable for initial method support, but long-term we should probably provide a first-class way to enforce accepted QUERY content types / 415 / 422 behavior.

The cache key for a QUERY request (Section 2 of [HTTP-CACHING]) MUST incorporate the request content (Section 6 of [HTTP-CACHING]) and related metadata (Section 8 of [HTTP]).

Now, we safely disables QUERY page caching, which fixes the current issue. But eventually we probably should implement body-aware QUERY cache support instead.

[michalsn]

Thanks for the updates.