These tables will hold texts of events, extracted from subtitles and
slide texts, which will be searchable later. The queue is used for
fetching all those text assets from Opencast.

This is useful to specify other trusted hosts, where Tobira may send
the sync login data to.

This will be part of the worker and is able to deal with a variety of
error cases. Figuring all this out took quite some time. I decided now
that ignoring assets for which Opencast returns something unexpected is
fine most of the time. Admins will be able to easily requeue these
failed events.

This can also deal with network errors or similar indications that OC
is not available at the moment, using an exponential backoff then.

What... like the explicit color choice is there to override terminal
detection. So why...?!

This was forgotten before: maybe some assets don't exist anymore after
an event was updated. Those entries shouldn't persist in the event_texts
table. By deleting all entries beforehand, we can also easily use a bulk
insert now (since we don't require `on conflict`). I extracted some
logic into a helper function to deduplicate code. I tested the users
upsert function after this change.

This allows you to queue or dequeue a specific set of events. In
particular the `queue --missing` is very relevant as Tobira sometimes
gives up on some events after too many failures.

I just tested this with our 12 core test Opencast (where Java serves
the files):

 2: ~125% CPU, ~1.1 MiB/s down      => 3m 2s
 4: ~230% CPU, ~2.0 MiB/s down      => 1m 42s
 8: ~380% CPU, ~3.5 MiB/s down      => 1m
16: ~600% CPU, ~5.5 MiB/s down      => 42s
32: CPU and downlink wildly varying => 37s

The main change is that texts with the same span are concatenated to
only be one entry in the index. This doesn't reduce the size of the
`texts` field in Meili, but that of the timespan index. This
optimization is mostly there for slide texts, not for captions.

But this commit also moves the build process into `FromSql` to avoid
a bunch of useless allocations. Ideally one would also avoid all the
intermediate `String` allocations, but that's not easily possible right
now.

It was only as wide as the metadata made the container, which is not
great.

This is still not very aggressive... I first wanted use 2 as threshold,
but ... looking at all chars encodable in 2 byte UTF-8... I cannot be
sure that it doesn't make sense to search for one individually. Pi came
to mind. We can always make this more aggressive later.

Mostly ignoring broken ranges

This rewrites the logic that creates the `textMatches` array for the
search API. Before, one Meili match was emitted as one text match, but
this had several problems. Most importantly, with two words in the
query, if those words would appear in a text right next to one another,
Meili would still generate two matches. They would have the same
timespan and Tobira would just show two divs on top of each other, only
one of which would be visible.

Now, for each individual text, we join all matches (with a limit) and
return only one `TextMatch`, but potentially with multiple highlight
ranges.

Still enough context and makes it a bit less "in your face".

The previous commits changed a lot -> a rebuild is necessary.

These failed due to the passage of time. We incorrectly used a locator
with "2 years ago" in it, which obviously fails at some point, given
that the dates stay constant.

Turns out `actions/upload-artifacts` introduced a breaking change where
hidden files are not included anymore by default. This also applies to
explicitly listed hidden files, which does not make any sense to me. But
oh well...

actions/upload-artifact#602

We want to distinguish different text matches in the frontend, so we
need to store the type at every point.

This is now closer to the old video portal and distinguishes between the
two different kind of matches.

Also seeing the preview image for the text matches makes it easier to
find a relevant spot in the video.

The segment preview images are not loaded in the initial GQL request as
it would increase response size quite a bit and is not necessary in most
cases. We simply load them on hover, i.e. when they will become used.

This increases the size of the dump from roughly 2.7MB to 11MB. But we
want the dump to be immediately fully useful and reflect real world
data, so we accept this increase.

No point in downloading it again and again. This is simple, no
invalidation is done and the dumps are keyed by the version.

Since the area for showing the text is made a bit smaller, we also use
less context in the backend.

This fix was a easier than anticipated (once I figured this out anyway).
The problem is: giving the `WithTooltip` a `z-index`, means that parent
element (containing both the trigger element and the tooltip), creates
a new stacking context. And a stacking context and its children behaves
as one unit in regards to other stacking contexts. So even setting the
z-index of the tooltip itself to 100, two timelines are two different
stacking contexts, so the 100 of the one tooltip is not rendered in
front of the 4 of the trigger elements of another timeline. So there
were two options:
- Either introduce another div in the floating components that would
  have the trigger element as children, but not the tooltip, and that
  could get a z-index then. But that would have required changing
  appkit.
- Remove the z-index from `WithTooltip` to avoid creating stacking
  contexts. First I thought the only way to do this is to remove the
  big clickable link area of the search results. And we might still do
  that, as it often brings annoying problems. But for this particular
  problem, the solution turned out easier than I thought.

Unfortunately, this required adding a new package. `react-icons` has
a super old version of lucide icons, even in its newest version. Since
almost all of our icons are from Lucide anyway, it makes sense to just
use their packages directly.