[configgrpc, confighttp] Consider removing `component.Host` from method signatures

[evan-bradley]

Component(s)

No response

Describe the issue you're reporting

While working with configgrpc and confighttp recently, I've found the host parameter in the ToClient and ToServer methods on the config corresponding structs in each module to be more cumbersome than helpful, and I think we should consider changing it before stabilizing these modules.

I think the following points are in favor of changing the host component.Host parameter to middlewares map[component.ID]component.Component (or similar):

1. For Collector-adjacent components that want to keep a similar configuration structure for gRPC/HTTP-related tasks and use configgrpc/confighttp for this, a host isn't necessarily already present and requires extra setup to use the methods. We recently encountered this situation in this Supervisor PR. This would also relieve tests of having to create a mock host; they could just create an extensions map.
2. The component.Host interface is stable and only has a GetExtensions method, so passing in the host doesn't do much in the way of encapsulating behavior: the ToClient/ToServer methods will only call GetExtensions.

The main point against this would be that these modules could take advantage of other host capabilities in the future through optional interfaces. At present I don't see this happening, but would be open to the opinions of others if we think it may. We could probably utilize the existing variadic options parameter in the future if something comes up, even if it would be a slightly unusual way to use it.

This would also be a fairly large breaking change, albeit with an easy work around: you just pass host.GetExtensions() instead of host to the config methods.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[evan-bradley]

We discussed this during the 2025-08-18 stability call and discussed the possibility of creating a WithMiddlewares option or similar to give the config structs access to the extensions map, but wanted to make sure we understood the context around the current state of the config modules first.

1. The question of why we pass component.Host in the first place was asked, and I tracked it down to this issue: Investigate if we should pass the Host not the extensions in ToServerOption #4012, which moved to use the host because the interface could provide additional capabilities in the future. I think this reasoning made sense at the time, but now that the host interface is stable with a single method, I think it's less compelling.
2. It was asked if middlewares are considered more experimental or are closer to being considered stable, and how frequently they're used. @jmacd do you have any insights here? I was told to ask you, but don't have much prior context.

Overall, I think moving this to an option that takes a map of extensions makes sense:

1. For non-Collector uses, allows explicitly disabling middlewares. If the option is not used, the config structs can print that middlewares aren't supported if one is specified, rather than just saying it wasn't found.
2. For Collector uses, it's simple to pass the option like you would pass the host today.

[jmacd]

Sounds good.

[jade-guiton-dd]

Filed #14162 to implement this change, will mark as ready for review after next release

[jade-guiton-dd]

@evan-bradley Pablo and I are concerned that using a WithMiddlewares option would make it easy for component authors to forget to pass it. Do you think it would be fine to keep it as a positional argument instead? Ie. just replacing host component.Host by middlewares map[component.ID]component.Component, with tests passing in nil.

[evan-bradley]

I'm slightly less concerned about that, but I do see the concern there. I think both options are about equivalent, especially given that we can just pass nil like you said.