This was previously linking to `elastic_full_index`. Looking at the size
of the `elastic_full_index` queue is much less valuable considering it
is ultimately just spinning up a bunch of `elastic_commit_indexer` jobs
which do all the heavy lifting and it's very likely the
`elastic_full_index` queue is drained in seconds (since there is no back
pressure) while the `elastic_commit_indexer` queue takes days to finish
draining.

There are also other queues at play which are indexing non-code
documents (eg. issues) but from experience these are drained quicker
than the `elastic_commit_indexer` queue when indexing projects so if we
had to pick one queue then `elastic_commit_indexer` is the best one to
show.

We could consider something more sophisticated in future but I wanted to
correct this for now since the `elastic_full_index` queue is not a
useful way to track progress.