control-plane: use btree index for log_lines

[psFried]

Description:

Replaces the current BRIN index on the internal.log_lines table with a btree index. The BRIN index would require queries to use the logged_at timestamp in the where clause in order for it to be effective. Neither the UI or flowctl do that currently. The btree index works well when only filtering on token, so this changes to just using that.

Notes for reviewers:

The main issue this is seeking to address is that clients are getting HTTP 500 responses when they try to fetch log lines during a publication or discover. Another option that might also work to address this would be to add where logged_at > (now() - '1h'::interval) to the query in the view_logs RPC. I decided to use the btree index instead because it felt somewhat less hacky.

BUT, we may still want a brin index on (only) logged_at, so that we can use it in a pg_cron job to clean out old logs. I've opted to ignore this for the time being, and address that in a future PR along with the cron job to delete the logs.

---

This change is 

[jshearer]

Reading your testing of this, it looks like it should help query perf in the short/medium term, and if we want the BRIN index back we can re-create it. LGTM 👍

[jgraettinger]

I see this is applied already, and it's not a big deal, but I would consider this a bug in usage of the table.

In any operational / live context, we're polling the table with a tight interval between SELECT's, and there's always a very recent timestamp for which you want logs after: either the timestamp at which the publication was created, or the biggest logged_at timestamp seen so far. The agent is designed such that logged_at is strictly ascending for exactly this purpose (you don't have to deal with late-arriving logs).

The BRIN index lets you very quickly discard pretty much the entire table, evaluating only the really recent stuff logged after the cursor logged_at.

[jgraettinger]

This also explains a bug I've noticed in flowctl: each poll of logs is re-printing all publication logs, rather than just printing incremental new logs. Looks like I forgot to push down a gt on logged_at right here