Move restore repo to internal router and invoke from command to avoid open the same db file or queues files

[lunny]

When execute the restore repo command and gitea is running, you may got errors to open queue files or sqlite database because the files have been locked.

This PR moves repo restore main logic to internal routers and send a http request to execute the command.

This also fixes the bug that units has been ignored from restore repository.

[codecov-commenter]

Codecov Report

Merging #15790 (26078d0) into main (17a7797) will increase coverage by 0.03%.
The diff coverage is 24.16%.

@@            Coverage Diff             @@
##             main   #15790      +/-   ##
==========================================
+ Coverage   43.97%   44.00%   +0.03%     
==========================================
  Files         678      681       +3     
  Lines       82047    82092      +45     
==========================================
+ Hits        36079    36126      +47     
+ Misses      40091    40087       -4     
- Partials     5877     5879       +2     

Impacted Files	Coverage Δ
cmd/restore_repo.go	0.00% <0.00%> (ø)
modules/migrations/dump.go	0.00% <0.00%> (ø)
modules/private/restore_repo.go	0.00% <0.00%> (ø)
routers/private/restore_repo.go	0.00% <0.00%> (ø)
routers/routes/goget.go	70.21% <70.21%> (ø)
routers/private/internal.go	85.00% <100.00%> (+0.38%)	⬆️
routers/routes/web.go	90.84% <100.00%> (+4.35%)	⬆️
models/gpg_key.go	53.51% <0.00%> (-0.57%)	⬇️
... and 8 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 038e1db...26078d0. Read the comment docs.

[zeripath]

OK one final context question.

Do we want these to be cancellable by cancelling the request or do we want them to just start the restoration in the background?

At the request looks to the user that the wait they're experiencing would imply that it is cancellable but it's not - and in fact the request will timeout after 60s because of the settings in modules/private - That will then look like it has failed but it will continue to do the migration in the background.

We could tie the migration to the myCtx.Req.GetContext() - and set no timeout - or we could stick it in the task queue or a separate go-routine.

[lunny]

OK. I think we can run it in another goroute and return immediately.

[lunny]

OK one final context question.

Do we want these to be cancellable by cancelling the request or do we want them to just start the restoration in the background?

At the request looks to the user that the wait they're experiencing would imply that it is cancellable but it's not - and in fact the request will timeout after 60s because of the settings in modules/private - That will then look like it has failed but it will continue to do the migration in the background.

We could tie the migration to the myCtx.Req.GetContext() - and set no timeout - or we could stick it in the task queue or a separate go-routine.

I have set the timeout as zero so that it will not timeout.

[zeripath]

Ok so with the timeout at 0, we're now giving the impression that the request is cancellable and now we should use the myCtx.Req.Context() instead of the hammer context

[zeripath]

We'll need to add some status updates in future but this is better.