Please consider a big refactor (including renaming probably) for this package before marking stable.

[atoulme]

          Please consider a big refactor (including renaming probably) for this package before marking stable.

Originally posted by @bogdandrutu in #9805 (comment)

[bogdandrutu]

1. I think the "client" name of the package is too generic and confusing;
2. Some (if not all) of this can be part of the consumer package since it is "propagated" via context between consumers;
3. Better understand why we need to propagate any of these objects for the entire collector. Can some be "component" specific?

[TylerHelmuth]

If we move this to consumer we'd be adding a direct dependency between confighttp/configgrpc and consumer, but I think thats ok. Considering the functionality within client exists to help share context between components I think this makes sense.

When we do the move we can expand some of the naming to include the keyword Connection. So Info could become ConnectionInfo, Addr becomes ConnectionAddr, Auth becomes ConnectionAuth, and Metadata becomes ConnectionMetadata. It is kinda verbose, but directly conveys what the struct represents. NewContext can potentially become NewContextWithConnectionInfo.

I would prefer not to restrict the Info struct to any specific component type. We don't restrict how components make connections, so I think it is valid for any component to be allowed to add its connection to the context and pass it own down the component pipeline. It should also be valid for any component to ask if there is an Info struct in the current ctx.