Default Branch Search is Too Slow

[aj-codecov]

Describe the bug
Default Branch search is so slow that it sometimes doesn't resolve for larger repos.

To Reproduce
Org > Repo > Configuration > General > default branch dropdown > search for something > it's slow
Expected behavior
It's at least fast enough that when searching for a branch name in a large repo like Sentry's that we actually surface a result instead of an infini-spinner.

Screenshots

[eliatcodecov]

It's unclear to me where precisely this problem is: front end, API , database. My guess is to probably hand this to someone to investigate from the API/database perspective to see if this search call can work better. It could also be benefitted potentially from a debounce on the front end if that's not already in place.

[suejung-sentry]

See PR description for discovery notes

We run branch search by name on the Configuration page of a repo - it's currently slow (~50 seconds in worst case, median ~10+seconds - Sentry board).

The branch name search is the GetBranches graphQL query and the below db query.

SELECT branches.branch, branches.repoid, branches.authors, branches.head, branches.base,
  branches.updatestamp
FROM branches
WHERE (
  branches.repoid = 111 AND UPPER(branches.branch::text) LIKE UPPER('%codecov%')
)
ORDER BY branches.updatestamp DESC
LIMIT 21;

I ran some tests against postgres prod and the EXPLAIN ANALYZE shows significant difference between running ILIKE vs. LIKE for the search (~10 ms vs. 5 seconds).
There is an index on branches.repoid and one on branches.repoid, branches.branch. From the query plans it looks like running with LIKE is running a custom columnar scan (full table scan on all 27 million rows of branches table) before then using the repoid index and filtering those rows by name. The query with ILIKE just uses the index then filters, so it's much faster.
explain analyze with LIKE:

explain analyze with ILIKE:

So this PR moves over to using ILIKE in the query. I suspect the reason for the difference between running with LIKE vs. ILIKE has to do with our collation settings for the table but those are risky to alter so I'd rather move to using ILIKE than trying to fix LIKE.

Other stuff:

• Django's docs say the existing icontains methods translates to a query of ILIKE, but it clearly doesn't. Some troubleshooting says maybe it's because our DATABASE ENGINE settings.py is not set to postgres, but everything I checked seems to imply that is done already.
• This from the Django forums seems to confirm their doc is just wrong. The Django folks recommend redefining the ORM hooks, but I gave it a shot and didn't do what I expected. Also seems risky to mess with it at that level.
• So the alternative I went with here is the .extra api that gets us what we need. Technically the docs say to use it as a last resort, but it seems to be the best solution for this now without restructuring our ORM in bigger ways.
• On the frontend we have a debounce (500 ms) for the query already, so unfortunately no further gains that way

Closes #2537