Fix lack of title search for posts

[Oaphi]

closes #387

And no, we can't just add a separate index for the title column, the way we use search we need the composite index

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.25%. Comparing base (1633fd6) to head (3062a26).
⚠️ Report is 6 commits behind head on develop.

Additional details and impacted files

Components	Coverage Δ
controllers	72.06% <ø> (ø)
helpers	82.96% <ø> (+0.52%)	⬆️
jobs	60.86% <ø> (ø)
models	89.17% <100.00%> (+0.12%)	⬆️
tasks	61.11% <ø> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trichoplax]

Not a suggestion, just a question to gain understanding:

And no, we can't just add a separate index for the title column, the way we use search we need the composite index

By "the way we use search" do you mean the way we implement it behind the scenes, or what we allow the user to do?

If it's just a matter of implementation, is there a benefit to having separate indexes for title and body, and returning results that match in either (the union of 2 searches)? My guess is that would mean less resources spent on storing and updating indexes, but a slightly slower search query? Is this a trade off between speed of search and speed of everything else? I don't know if either matters at present.

[ArtOfCode-]

Approve with note for deployment: this is going to take forever to migrate. Don't merge yet - we'll merge just before we're ready to deploy it.

[cellio]

Let's do this after the deploy that we're readying now. (Reduce risk now, then do this in the next deploy.)

[Oaphi]

Note: there's going to be a couple more changes (should've probably set it in the draft state for now)

[Oaphi]

By "the way we use search" do you mean the way we implement it behind the scenes, or what we allow the user to do?

@trichoplax mostly just noting that because it was suggested to use a separate index in the previous discussion, but attempting to do so without changing how sanitize_for_search works completely will cause a "Can't find FULLTEXT index matching the column list" DB error.

We can separate the index out later when (if?) we allow to explicitly search only in title / body (like how SE does with the title: operator)

P.S. Added the "blocked" label just in case as per the deployment note