WIP: Defer last commit info

[zeripath]

We use the commitinfo cache because we recognise that generating its data is slow. However, when we have a commit info cache we allow it to cause the page to not be rendered until the commit info has been calculated.

This PR simply changes the code to allow the page to still be rendered at least partially whilst we're waiting.

[codecov-commenter]

Codecov Report

Merging #16063 (67b817e) into main (fb3ffeb) will decrease coverage by 0.00%.
The diff coverage is 52.80%.

@@            Coverage Diff             @@
##             main   #16063      +/-   ##
==========================================
- Coverage   44.19%   44.18%   -0.01%     
==========================================
  Files         694      695       +1     
  Lines       82324    82432     +108     
==========================================
+ Hits        36379    36422      +43     
- Misses      40057    40107      +50     
- Partials     5888     5903      +15     

Impacted Files	Coverage Δ
modules/repository/cache.go	35.00% <0.00%> (-1.85%)	⬇️
routers/init.go	60.00% <0.00%> (-1.65%)	⬇️
routers/web/repo/commit.go	28.83% <0.00%> (-0.11%)	⬇️
modules/git/commit_info_nogogit.go	63.47% <7.14%> (-3.66%)	⬇️
routers/web/repo/view.go	41.03% <16.66%> (-0.29%)	⬇️
modules/repository/last_commit_queue_nogogit.go	60.71% <60.71%> (ø)
modules/git/last_commit_cache_nogogit.go	39.65% <100.00%> (+4.46%)	⬆️
modules/git/notes_nogogit.go	70.73% <100.00%> (+0.73%)	⬆️
modules/process/manager.go	75.00% <100.00%> (+2.16%)	⬆️
modules/queue/queue_channel.go	91.66% <0.00%> (-3.34%)	⬇️
... and 6 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fb3ffeb...67b817e. Read the comment docs.

[techknowlogick]

tiniest of nits. Still going through the other code though.

[zeripath]

Things to be aware of:

The use of a queue with the default workers of 0 and boost of 1 with queue length 20 means that there is only 1 repository getting its commit info generated at a time unless there are 20 waiting. We may want to increase the number of boost workers for this queue by default.

[zeripath]

In light of information found in #16035 I think I'm going to have to make this WIP and have another think.

A different solution is required.

[tuaris]

@zeripath I am wondering what prompted you to rethink this? Unless I am misunderstanding the proposed solution, #16035 is irrelevant?

The way I understand the approach is:

1. Remove the 'on the fly' extraction of the commit message via git log during page rendering.
2. Instead look for the commit message as a value in a SQL database, Elasticsearch, or this new Ledis thing (I don't believe using Redis or Memcache make sense here).
3. If there is no value then display nothing (perfectly acceptable behavior).
4. A background process will fill/update/delete the SQL/Elasticsearch values.

[lunny]

the queue name is not right.

[delvh]

Can this PR be closed then as #16467 got merged now?

[zeripath]

@delvh whilst this does do things differently and does some novel things I think you're right and I'm gonna close it.