[LifecycleManager] Adding shutdown signal

[synzhu]

This PR updates LifecycleManager to have a shutdown signal which can be used by the component using it to know when shutdown has commenced.

[codecov-commenter]

Codecov Report

Merging #1077 (d4093fb) into master (95c99c0) will decrease coverage by 0.00%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master    #1077      +/-   ##
==========================================
- Coverage   53.34%   53.34%   -0.01%     
==========================================
  Files         318      318              
  Lines       21556    21559       +3     
==========================================
  Hits        11500    11500              
- Misses       8484     8487       +3     
  Partials     1572     1572              

Flag	Coverage Δ
unittests	53.34% <66.66%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
module/lifecycle/lifecycle.go	98.18% <66.66%> (-1.82%)	⬇️
module/mempool/epochs/transactions.go	94.73% <0.00%> (-5.27%)	⬇️
cmd/util/ledger/migrations/storage_v4.go	41.56% <0.00%> (-0.61%)	⬇️

---

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 95c99c0...d4093fb. Read the comment docs.

[huitseeker]

Discussed that offline, but I wonder if this simple approach isn't just a detour on the way towards threading a context. See https://github.com/dapperlabs/flow-go/issues/5720

[vishalchangrani]

isn't this already conveyed by shutdownCommenced ?

[synzhu]

Yes, but shutdownCommenced is not something which the user of the lifecycle manager has access to. This feature enables someone to "subscribe" to the shutdown commenced event (by reading from the channel), so goroutines launched by the user of the lifecycle can use this to know when they are signalled to shutdown

[synzhu]

Discussed that offline, but I wonder if this simple approach isn't just a detour on the way towards threading a context. See dapperlabs/flow-go#5720

@huitseeker Thanks for bringing this up, after some more thought I actually tend to agree. However, I realized that actually a lot more work needs to be done to refactor our codebase to be able to use contexts properly, at the root of which lies splitting the capability to check the state of a component (ReadyDone) from the capability to start and stop it (a new Runnable interface with a method Run(context.Context)).

I think Leo actually had a good point here about each component having a single owner. What I realize now is that we actually want to model a Go program as a call-graph where each goroutine has a single parent:

If a goroutine is responsible for creating a goroutine, it is also responsible for ensuring it can stop the goroutine.

If we have this, then contexts provide a very composable, elegant solution for managing branches of our call-graph:

• If your component needs to cancel functions below it in the call-graph in some manner, then it will call one of these functions and pass in the Context it was given, and then pass the Context returned into its children.
• If component doesn’t need to modify the cancellation behavior, then it simply passes on the Context it was given.

In this way, successive layers of the call-graph can create a Context that adheres to their needs without affecting their parents.

By splitting into two interfaces, we can ensure that only a single goroutine will have access to a component's Run method, while multiple components may have access to Ready and Done.