proposal: os/signal: NotifyContext should pass the signal as a cause

[lbcjones]

Proposal Details

Propose to:

1. change the type signature of signal.NotifyContext() to be: func(context.Context, ...os.Signal) (context.Context, context.CancelCauseFunc)

2. modify the implementation so that, when the context is cancelled due to receipt of a signal, context.Cause(ctx) should return a suitably defined error identifying the specific signal that caused the cancellation

[gabyhelp]

Related Issues

• proposal: os/signal: enhance NotifyContext() to return a context with cancel cause #66032 (closed)
• os/signal: NotifyContext should communicate the signal via context.WithCancelCause #60733 (closed)
• proposal: os/signal: Provide a new error type to communicate the signal triggered context cancellation #60756
• proposal: add context cancellation mechanisms to os/signal #16472 (closed)
• os/signal: add NotifyContext function #37255 (closed)
• context: add APIs for writing and reading cancelation cause #51365 (closed)
• proposal: context.WithSignal #21521 (closed)
• proposal: context: context.Cause should return a wrapped error #63759
• context: add APIs for setting a cancelation cause when deadline or timer expires #56661 (closed)
• proposal: context: support semantic error mapping by allowing Cause to return a wrapped parent error #74715 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

An API change would be a breaking change, we're not going to do that.
The proposed API also doesn't make sense, stop is to cancel the notification, not cancel the context.

I think NotifyContext can just be changed to use context.WithCancelCause internally