Fix shutdown waitgroup panic

[lunny]

This PR fixes a panic issue in the WaitGroup that occurs when Gitea is shut down using Ctrl+C.
It ensures that all active connection pointers in the server are properly tracked and forcibly closed when the hammer shutdown is invoked.
The process remains graceful — the normal shutdown sequence runs before the hammer is triggered, and existing connections are given a timeout period to complete gracefully.

This PR also fixes no logger writer problem. Now the log close will only be invoked when the command exit.

• Fixes Ctrl +C shudown Gitea caused WaitGroup panic #35468
• Fixes [no logger writer]: Queue "repo-archive" stops running #35551
• Fixes Ctrl+C result in panic #35559
• Replace fix(graceful): prevent WaitGroup panic on Ctrl+C shutdown #35578

[wxiaoguang]

1. Fixes #35648 seems to be a wrong reference, 35648 is for OAuth2
2. I don't think it's right to keep doing "// Check for shutdown signal during startup", the "shutdown" can occur exactly after your check, then the check doesn't really help anything.
3. For the connections, if you decided to use "connections map", what does wl.server.wg.Add(1) do? Does it still make sense?
   • wg.Wait is used for waiting for the open connections, so it is still useful (BUT not right)
   • Maybe the Add-After-Wait data-race still exists (much more rare than before, better than before): doShutdown -> setState(stateShuttingDown) -> new conn comes -> listener.Close() -> wg.Wait() -> new conn wg.Add()

[lunny]

1. Fixes #35648 seems to be a wrong reference, 35648 is for OAuth2

2. I don't think it's right to keep doing "// Check for shutdown signal during startup", the "shutdown" can occur exactly after your check, then the check doesn't really help anything.

3. For the connections, if you decided to use "connections map", what does wl.server.wg.Add(1) do? Does it still make sense?

   • wg.Wait is used for waiting for the open connections, so it is still useful
   • Maybe the Add-After-Wait data-race still exists (much more rare than before, better than before): doShutdown -> setState(stateShuttingDown) -> new conn comes -> listener.Close() -> wg.Wait() -> new conn wg.Add()

• 1 is a typo that it should be Ctrl +C shudown Gitea caused WaitGroup panic #35468
• The checking could check the situation ctrl+c before web listening. I can try to reduce them.
• Once listener closed, there should be no new connection coming.

[wxiaoguang]

The checking could check the situation ctrl+c before web listening. I can try to reduce them.

You can reproduce doesn't mean the fix is right.

Once listener closed, there should be no new connection coming.

I am showing the "DATA-RACE". "listener.Close" and "Accept" are in different threads.

Anyway, talk is cheap, I showed you my code.

[wxiaoguang]

This PR also fixes no logger writer problem. Now the log close will only be invoked when the command exit.
Fixes [no logger writer]: Queue "repo-archive" stops running #35551

Your change is also wrong. I have told you the root problem and it is not easy to fix. #35551 (comment)

[yp05327]

I’m not familiar with the sync functions, so this is just a question.
Should Broadcast be called before Unlock?
In the code above, Broadcast is always called before Unlock.
I asked AI about it, and it said it isn’t safe, so I left this comment.

[wxiaoguang]

Maybe AI didn't read the Golang doc: https://pkg.go.dev/sync#Cond.Broadcast

[lunny]

I think @yp05327 means it’s inconsistent because, on line 209, the Broadcast function is called before the lock is released.

[wxiaoguang]

I asked AI about it, and it said it isn’t safe, so I left this comment.

I think @yp05327 means it’s inconsistent because ....

He means it isn’t safe, not inconsistent

Does "not safe" mean "inconsistent" in your mind?