ggcr: Pass retryBackoff to transport.NewRetry in the remote pkg

[somtochiama]

Describe the feature

Not a bug report but a feature request.

It would be great if the remote.BackOff set in options gets passed now to the created transport in

go-containerregistry/pkg/v1/remote/options.go

Line 165 in a927d7c

o.transport = transport.NewRetry(o.transport, transport.WithRetryPredicate(defaultRetryPredicate), transport.WithRetryStatusCodes(o.retryStatusCodes...))

.

This would enable people to configure some parts of the retry operation without providing our own transport.

To Reproduce

Expected behavior

The retry transport is created with the remote.BackOff set in option.

Additional context

Add any other context about the problem here.

• Version of the module
• Registry used (e.g., GCR, ECR, Quay)

[somtochiama]

@jonjohnsonjr @imjasonh Sorry for labelling this as a bug, it's really a question.
Is it a reasonable ask/feature request to have the retry transport configured with remote backoff
e.g

o.transport = transport.NewRetry(o.transport, transport.WithRetryPredicate(defaultRetryPredicate), transport.WithRetryStatusCodes(o.retryStatusCodes...), transport.WithRetryBackoff(o.retryBackoff)))

[imjasonh]

This seems reasonable to me. It sounds like it might even be an oversight? @jonjohnsonjr does that sound right to you?

[jonjohnsonjr]

#1628 (comment)

We can document better what it's for.

[somtochiama]

@jonjohnsonjr does this mean the remote backoff isn't intended for configuring retries on the transport?

If so, will you consider adding an option that is? Configuring a new transport when you only want to modify a backoff means copying some parts of the code in crane (like the default predicate and some other parts from the internal retry package) and isn't the best experience

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.