Add AddOptionWithValidation interface to support error reporting in service options

[Umang01-hash]

Is your feature request related to a problem? Please describe.
Our current service.Options interface doesn't support error reporting. This creates a risk of silent failures when invalid configurations are used as options.

package service

type Options interface {
	AddOption(h HTTP) HTTP
}

When using AddOption, validation errors cannot be surfaced to the caller. Consumers must use separate validation methods or constructors, creating a disconnected validation flow.

Describe the solution you'd like

Create a new interface AddOptionWithValidation that returns an error:

type AddOptionWithValidation interface {
    AddOptionWithValidation(h HTTP) (HTTP, error)
}

Services can check for this interface before falling back to the standard Options interface, enabling proper error handling while maintaining backward compatibility.

[aryanmehrotra]

this seems to be a breaking change, can you add some examples if not

[Umang01-hash]

This is not a breaking change because we're adding a new interface alongside the existing one, not replacing it. Here's how it works:

Backward Compatibility:

• The original Options interface remains unchanged.
• Existing code using Options.AddOption() continues to work exactly as before.
• The framework tries the new interface first, then falls back to the old one.

Implementation Example:

• New introduced interface:

package service

type Options interface {
	AddOption(h HTTP) HTTP
}

// AddOptionWithValidation extends Options with error reporting capability
type AddOptionWithValidation interface {
	AddOptionWithValidation(h HTTP) (HTTP, error)
}

• New method NewHTTPServiceWithValidation:

// NewHTTPServiceWithValidation provides error handling for options
func NewHTTPServiceWithValidation(serviceAddress string, logger Logger, metrics Metrics, options ...interface{}) (HTTP, error) {
	h := &httpService{
		Client:  &http.Client{},
		url:     serviceAddress,
		Tracer:  otel.Tracer("gofr-http-client"),
		Logger:  logger,
		Metrics: metrics,
	}

	var svc HTTP = h

	// Process options with validation support
	for _, o := range options {
		// Try validation interface first
		if validator, ok := o.(AddOptionWithValidation); ok {
			var err error
			svc, err = validator.AddOptionWithValidation(svc)
			if err != nil {
				return nil, err
			}
		} else if option, ok := o.(Options); ok {
			// Fall back to standard interface
			svc = option.AddOption(svc)
		} else {
			return nil, fmt.Errorf("option %T doesn't implement either Options or AddOptionWithValidation", o)
		}
	}

	return svc, nil
}

Usage Example:

// Before - errors silently ignored
app.AddHTTPService("service1", "http://example.com", &service.RateLimiterConfig{Requests: -5})

// After - errors properly reported
err := app.AddHTTPServiceWithValidation("service1", "http://example.com", &service.RateLimiterConfig{Requests: -5})
if err != nil {
    // Handle error: "invalid request rate: -5"
}

This approach prevents the silent failures we've been seeing with invalid configurations while maintaining complete backward compatibility.

[aryanmehrotra]

The original Options interface remains unchanged.
Existing code using Options.AddOption() continues to work exactly as before.
The framework tries the new interface first, then falls back to the old one.

If this is the case then we dont need to actually have a fallback mechanism because we have a different method altogether - AddHTTPServiceWithValidation based on this it should work fine - this being said the current options will not work and at the same time AddHTTPServiceWithValidation is not doing exactly what is said if we allow both.

Also in the new method options ...interface{} is too generic and not an idiomatic go approach.

[Umang01-hash]

@aryanmehrotra existing Options and current constructors keep working.

• If callers keep using the old NewHTTPService (or app.AddHTTPService) with types that implement Options, nothing breaks.
• NewHTTPServiceWithValidation is opt-in. It exists to let callers get validation errors when they want them.
• The only reason to keep a runtime fallback from AddOptionWithValidation → Options is if you expect mixed/new code to pass both old and new option implementations to the same call.

Also I thought we can have ValidatorOption interface instead of new AddOptionWithValidation:

package service

type Options interface {
	AddOption(h HTTP) HTTP
}

type ValidatorOption interface {
	Options
	Validate() error
}

We can make NewHTTPServiceWithValidation accept options ...Options (typed variadic).
For each option, if it implements ValidatorOption call Validate() first; then call AddOption().