Refactor fx service Start/Stop

[dnr]

What changed?

• Change the four main Service Start methods to no longer block
• But also run synchronously in fx lifecycle (except for the final Serve call)
• Use fx.StartStopHook to simplify code
• Get rid of s.status atomic ops since fx will serialize Start/Stop
• Get rid of stopChan as well

Why?
Allow more of service start/stop to be serialized by fx lifecycle, to avoid bugs when e.g. Stop is called while Start is still running.

How did you test it?
manually and integration tests

Potential risks

Is hotfix candidate?

[MichaelSnowden]

🏡

[dnr]

Just FYI, there's still a bug (#4174) you can observe with the dev server where if you let it finish starting, it'll stop within a couple seconds (on interrupt signal). But if you interrupt it before it finishes starting, it'll take 10 seconds. I'm not sure exactly where that is yet, but it was there before this PR also. In theory this might make that easier to find/fix

[MichaelSnowden]

Just FYI, there's still a bug (#4174) you can observe with the dev server where if you let it finish starting, it'll stop within a couple seconds (on interrupt signal). But if you interrupt it before it finishes starting, it'll take 10 seconds. I'm not sure exactly where that is yet, but it was there before this PR also. In theory this might make that easier to find/fix

I have a hunch that it's #3818 or something of a similar nature (wg.Wait() in a stop method). I think you plan on landing this PR regardless of that, which I totally support. If we do want to troubleshoot that bug, I think fx logs something before each stop method, right? And, if not, probably there's a hook in the fx logger we can utilize.