Use pg_hint_plan for IssuableFinder

What does this MR do?

Initial pg_hint_plan test/implementation in the IssuableFinder

Behind a feature flag initially.

This will generate SQL queries that look like:

  Issue Load (3.1ms)  SELECT /*+ BitmapScan(issues idx_issues_on_project_id_and_created_at_and_id_and_state_id) */ "issues".* FROM "issues" LEFT OUTER JOIN milestones ON issues.milestone_id = milestones.id WHERE "issues"."project_id" = $1 AND ("issues"."state_id" IN (1)) AND "issues"."issue_type" IN ($2, $3) AND ("issues"."title" ILIKE '%test%' OR "issues"."description" ILIKE '%test%') ORDER BY milestones.due_date IS NULL, milestones.id IS NULL, milestones.due_date ASC, "issues"."id" DESC LIMIT $4 OFFSET $5

Thanks to the hints being comments, if pg_hint_plan is not installed nothing happens.

SQL timings

With hint BitmapScan, specifying idx_issues_on_project_id_and_created_at_and_id_and_state_id index

Explain here: https://explain.depesz.com/s/Q8Qj
Query:

/*+ BitmapScan(issues idx_issues_on_project_id_and_created_at_and_id_and_state_id) */
SELECT "issues".* FROM "issues" LEFT OUTER JOIN milestones ON issues.milestone_id = milestones.id WHERE "issues"."project_id" = 278964 AND ("issues"."state_id" IN (1)) AND "issues"."issue_type" IN (0, 1) AND ("issues"."title" ILIKE '%elastic%' OR "issues"."description" ILIKE '%elastic%') ORDER BY milestones.due_date IS NULL, milestones.id IS NULL, milestones.due_date ASC, "issues"."id" DESC LIMIT 20 OFFSET 0

Timings/buffer

Time: 10.833 s
  - planning: 10.742 ms
  - execution: 10.822 s
    - I/O read: 8.672 s
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 14639 (~114.40 MiB) from the buffer pool
  - reads: 49787 (~389.00 MiB) from the OS file cache, including disk I/O
  - dirtied: 923 (~7.20 MiB)
  - writes: 0

Without any hint:

Explain here: https://explain.depesz.com/s/7Vau
Query is the same as above, just no hint

Timings/buffers

Time: 22.653 s
  - planning: 10.494 ms
  - execution: 22.643 s
    - I/O read: 21.276 s
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 17677 (~138.10 MiB) from the buffer pool
  - reads: 14714 (~115.00 MiB) from the OS file cache, including disk I/O
  - dirtied: 127 (~1016.00 KiB)
  - writes: 0

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Related to #204720 (closed)