Drop context.Context implementation from Deadline

Deadline never satisfied the Context contract. Set revives it, so Err
goes from non-nil back to nil and Done hands out a new channel while
earlier holders still see the old one closed: two observers of the
same "context" disagreeing permanently. Any context derived from it
can panic in the standard library, because both propagateCancel paths
read parent.Err() after observing Done, and cancelCtx.cancel panics
on a nil error. This reproduces today with no callback API involved.

Dropping the no-op Value method breaks the interface assertion and
turns those derivations into compile errors. Callers that want a
context should use Deadline.Context, which is monotonic. Set, Done,
Err and Deadline are untouched: across pion/transport, pion/dtls and
pion/sctp the only methods invoked on a Deadline are Set and Done.

Known downstream fallout, both passing a Deadline to an unexported
function that takes a context.Context:
  pion/dtls  conn.go:586    c.contextWithClose(c.writeDeadline)
  pion/sctp  stream.go:330  sendPayloadData(s.writeDeadline, chunks)

Author: paulwe

deadline/deadline.go

@@ -28,10 +28,7 @@ func init() {
 	exceededContext = ctx
 }
 
-var _ context.Context = (*Deadline)(nil)
-
 // Deadline signals updatable deadline timer.
-// Also, it implements context.Context.
 type Deadline struct {
 	mu     sync.RWMutex
 	timer  timer
@@ -170,8 +167,3 @@ func (d *Deadline) Deadline() (time.Time, bool) {
 
 	return d.deadline, true
 }
-
-// Value returns nil.
-func (d *Deadline) Value(any) any {
-	return nil
-}