compute/metadata initial SubscribeWithContext request lacks timeout, can lead to hung threads #20487

Client

e.g. compute/metadata

Environment

go1.26.6 linux/amd64

Code and Dependencies

Callers can use metadata.Subscribe (or metadata.SubscribeWithContext) in order to monitor for changes to metadata and respond to them:

func (m *CfgWatcher) waitForChange(ctx context.Context) {
    if m.cacheFirstConfig { ... }
    desiredConfigPath := fmt.Sprintf("instance/attributes/%v", desiredConfigAttributeKey)
    ticker := time.NewTicker(m.retrySubscribeInterval)
    for {
        err := metadata.Subscribe(desiredConfigPath, m.processUpdate)
        log.V(2).InfoContextf(ctx, "metadata.Subscribe to key %q returned with err: %v", desiredConfigPath, err)
        <-ticker.C
    }
}

Expected behavior

metadata.Subscribe() should return a value shortly after the metadata is updated, or return an error if subscribing fails.

Actual behavior

If the initial subscription GET fails to respond (due to stuck HTTP request, network issue, metadata server issue), this can cause the thread to hang forever, even though the metadata is not being monitored. Passing a timeout-bearing context with metadata.SubscribeWithContext is insufficient to be resilient to hung connections, because the inner GET is an intentionally long-lived one (a hanging get) -- any timeout appropriate for the outer GET is probably not appropriate for the inner one. Subscribe() should enforce separate timeouts for these two phases.

Additional context

Bug with additional context: b/549027168