It's common to create a context early in a test body, then do setup work
unrelated to that context. By the time the context is actually used, it
may have already timed out. This was detected as test failures in #21091.

The new Context() function returns a context that resets its timeout when
accessed from new lines in the test file. The timeout does not begin until
the context is first used (lazy initialization).

This is useful for integration tests that pass contexts through many
subsystems, where each subsystem should get a fresh timeout window.

Key behaviors:
- Timer starts on first Done(), Deadline(), or Err() call
- Value() does not trigger initialization (used for tracing/logging)
- Each unique line in a _test.go file gets a fresh timeout window
- Same-line access (e.g., in loops) does not reset
- Expired contexts cannot be resurrected

Limitations:
- Wrapping with a child context (e.g., context.WithCancel) prevents resets
  since the child's methods don't call through to the parent
- Storing the Done() channel prevents resets on subsequent accesses

The original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup work
unrelated to that context. By the time the context is actually used, it
may have already timed out. This was detected as test failures in #21091.

The new Context() function returns a context that resets its timeout when
accessed from new lines in the test file. The timeout does not begin until
the context is first used (lazy initialization).

This is useful for integration tests that pass contexts through many
subsystems, where each subsystem should get a fresh timeout window.

Key behaviors:
- Timer starts on first Done(), Deadline(), or Err() call
- Value() does not trigger initialization (used for tracing/logging)
- Each unique line in a _test.go file gets a fresh timeout window
- Same-line access (e.g., in loops) does not reset
- Expired contexts cannot be resurrected

Limitations:
- Wrapping with a child context (e.g., context.WithCancel) prevents resets
  since the child's methods don't call through to the parent
- Storing the Done() channel prevents resets on subsequent accesses

The original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup work
unrelated to that context. By the time the context is actually used, it
may have already timed out. This was detected as test failures in #21091.

The new Context() function returns a context that resets its timeout when
accessed from new lines in the test file. The timeout does not begin until
the context is first used (lazy initialization).

This is useful for integration tests that pass contexts through many
subsystems, where each subsystem should get a fresh timeout window.

Key behaviors:
- Timer starts on first Done(), Deadline(), or Err() call
- Value() does not trigger initialization (used for tracing/logging)
- Each unique line in a _test.go file gets a fresh timeout window
- Same-line access (e.g., in loops) does not reset
- Expired contexts cannot be resurrected

Limitations:
- Wrapping with a child context (e.g., context.WithCancel) prevents resets
  since the child's methods don't call through to the parent
- Storing the Done() channel prevents resets on subsequent accesses

The original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup work
unrelated to that context. By the time the context is actually used, it
may have already timed out. This was detected as test failures in #21091.

The new Context() function returns a context that resets its timeout when
accessed from new lines in the test file. The timeout does not begin until
the context is first used (lazy initialization).

This is useful for integration tests that pass contexts through many
subsystems, where each subsystem should get a fresh timeout window.

Key behaviors:
- Timer starts on first Done(), Deadline(), or Err() call
- Value() does not trigger initialization (used for tracing/logging)
- Each unique line in a _test.go file gets a fresh timeout window
- Same-line access (e.g., in loops) does not reset
- Expired contexts cannot be resurrected

Limitations:
- Wrapping with a child context (e.g., context.WithCancel) prevents resets
  since the child's methods don't call through to the parent
- Storing the Done() channel prevents resets on subsequent accesses

The original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup work
unrelated to that context. By the time the context is actually used, it
may have already timed out. This was detected as test failures in #21091.

The new Context() function returns a context that resets its timeout when
accessed from new lines in the test file. The timeout does not begin until
the context is first used (lazy initialization).

This is useful for integration tests that pass contexts through many
subsystems, where each subsystem should get a fresh timeout window.

Key behaviors:
- Timer starts on first Done(), Deadline(), or Err() call
- Value() does not trigger initialization (used for tracing/logging)
- Each unique line in a _test.go file gets a fresh timeout window
- Same-line access (e.g., in loops) does not reset
- Expired contexts cannot be resurrected

Limitations:
- Wrapping with a child context (e.g., context.WithCancel) prevents resets
  since the child's methods don't call through to the parent
- Storing the Done() channel prevents resets on subsequent accesses

The original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup work
unrelated to that context. By the time the context is actually used, it
may have already timed out. This was detected as test failures in #21091.

The new Context() function returns a context that resets its timeout when
accessed from new lines in the test file. The timeout does not begin until
the context is first used (lazy initialization).

This is useful for integration tests that pass contexts through many
subsystems, where each subsystem should get a fresh timeout window.

Key behaviors:
- Timer starts on first Done(), Deadline(), or Err() call
- Value() does not trigger initialization (used for tracing/logging)
- Each unique line in a _test.go file gets a fresh timeout window
- Same-line access (e.g., in loops) does not reset
- Expired contexts cannot be resurrected

Limitations:
- Wrapping with a child context (e.g., context.WithCancel) prevents resets
  since the child's methods don't call through to the parent
- Storing the Done() channel prevents resets on subsequent accesses

The original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup work
unrelated to that context. By the time the context is actually used, it
may have already timed out. This was detected as test failures in #21091.

The new Context() function returns a context that resets its timeout when
accessed from new lines in the test file. The timeout does not begin until
the context is first used (lazy initialization).

This is useful for integration tests that pass contexts through many
subsystems, where each subsystem should get a fresh timeout window.

Key behaviors:
- Timer starts on first Done(), Deadline(), or Err() call
- Value() does not trigger initialization (used for tracing/logging)
- Each unique line in a _test.go file gets a fresh timeout window
- Same-line access (e.g., in loops) does not reset
- Expired contexts cannot be resurrected

Limitations:
- Wrapping with a child context (e.g., context.WithCancel) prevents resets
  since the child's methods don't call through to the parent
- Storing the Done() channel prevents resets on subsequent accesses

The original fixed-timeout behavior is available via ContextFixed().