[Spike] Investigate potential architecture for an improved Commit list (backend)

Context

Following a frontend spike (#525172 (closed)) validating a technical path for reusing existing frontend components to build an improved Commit List, we'd like to do the same and uncover a potential path for implementation in the backend.

The (non-final) guidance we've received from UX is that this page would likely use a FilteredSearch approach (like the UI used in Issues/MRs/Epics list pages).

Please read the updated description in the epic of this effort: &17482

Feature set

MVC:

• Will target mimicking existing functionality
  • Search by Author OR search by text (ideally the implementation would support searching both at once)
• Current search fields
  • author
  • message
  • sha
  • branch

Post-MVC:

• Proposed search fields to add (priority in bold):
  • date range High
    • created before, created after, committed before, committed after
  • pipeline status High
    • There may be technical restraints from the CI/CD team side &17482 (comment 2462748058)
  • tags/branches with wildcards Medium
  • comitter Low
  • badge Low
• Awaiting verification from UX/PM:
  • Type (is merge commit, is not merge commit)
  • Signed (is signed, is not signed)

Research

Incomplete list of open questions:

• Can we leverage GraphQL queries?
• Can we support multiple conditions at once?
• What architectural changes do we need to make these queries performant?
• Can/should we leverage the advanced finders being outlined here to unlock searching commits elsewhere (global search): gitlab-com/content-sites/handbook!12300 (closed)
• ...?

Goal

Identify the steps necessary to build the Backend in a sustainable way to provide ability to filter commit lists in multiple useful ways