[fix][fn] Honour negativeAckRedeliveryDelayMs in the Go function runtime

[david-streamlio]

Fixes #26409
Master Issue: #26404

Motivation

SourceSpec.negativeAckRedeliveryDelayMs sets how long the broker waits before redelivering a negatively acknowledged message. The Go runtime negatively acknowledges on failure (instance.go:389-397, shouldNackInputOnFailure) but never configured the delay — NackRedeliveryDelay was absent from every ConsumerOptions it builds, so the client default of one minute always applied.

A function configured for fast retry, or for a long back-off from a struggling downstream, silently got neither. The Java runtime applies it; the Python runtime has the same gap, with a fix open at #26413.

Modifications

Add resolveNackRedeliveryDelay and set NackRedeliveryDelay on all four ConsumerOptions in setupConsumer — the regex and non-regex branches of both the receiver-queue-size path and the default path.

The field is a proto3 scalar with no presence, so an unset value reads as 0. Only a positive value produces a duration; zero leaves ConsumerOptions at its zero value, which the client treats as unset. That matches the guard JavaInstanceRunnable applies (if (sourceSpec.getNegativeAckRedeliveryDelayMs() > 0)) and means a function that does not configure the delay is unaffected.

Note this touches the same function as #26414 (retainOrdering / retainKeyOrdering), which is filed against a sibling issue under the same master issue. The two are independent — different fields, different lines — but whichever merges second will need a trivial rebase.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• Four table-driven cases in pf/nackDelay_test.go: unset leaving the client default; milliseconds converted to a duration; a sub-second value preserved; and the client default expressed explicitly still round-tripping.
• Confirmed the tests are not vacuous: making resolveNackRedeliveryDelay return 0 unconditionally fails the suite.
• go build ./... and the full go test ./pf/ pass; go vet reports the same three pre-existing lock-copy warnings as master and no new ones.

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• Anything that affects deployment

A Go function already deployed with --negative-ack-redelivery-delay gets the configured delay on its next restart instead of the 60s default. That is the option taking effect for the first time, but it is a behaviour change for anyone who set it and adapted to it being ignored. A function that does not set it is unaffected.

Documentation

• doc-required
• doc-not-needed
• doc
• doc-complete

The option is already documented; this makes the Go runtime honour it.