Add option to specify propagators for httptrace and grpctrace plugins

[rghetia]

ochttp allows specifying propagators. Similar option should be added to httptrace and grpctrace

[krnowak]

After having a look, I'm not sure how to solve it. grpctrace and httptrace (not the clienttrace part) are basically free functions Inject and Extract. So there is no receiver object that could hold configurable propagators. So I see three options:

1. Leave it mostly alone, document that those plugins are using global propagators. Troublesome if we want to use both plugins with in the process, each with different propagators.
2. Add plugin-specific global propagators.
3. Add a propagator parameter to the free function. Maybe to avoid the hassle of updating the callsites, we could add it as propagators ...propagation.Propagators parameter, so grpctrace.Inject(ctx, metadata) will still use the global propagators, but grpctrace.Inject(ctx, metadata, myprops) will use the provided one.

After looking a bit more at both of the plugins, I propose another option:

4. Nuke them. Value added by grpctrace is mostly in wrapping *metadata.MD into a thing that implements the HTTPSupplierinterface. Maybe this could be exported. httptrace has kinda no value - the Extract function has an extra return value (attributes) that currently only contain request URL. Other than that, both plugins are basically unpacking stuff from context. I'm not sure how useful is this.

[paivagustavo]

I'm big +1 to creating a new http plugin similar to ochttp, with the current one we cannot assign the status of the request neither metrics. If needed I can work on it, this has been an issue for me for a while and I didn't have the time to look at it.

I think I've missed the othttp plugin 🤦‍♂, just ignore me.

[Aneurysm9]

4. Nuke them.

The httptrace.ClientTrace implementation is useful, though it could perhaps be moved to the contrib repo. Otherwise +1.

The existing plugins are used in the examples, so rewriting the examples to use the propagation package directly would be in order.

[krnowak]

1. Nuke them.

The httptrace.ClientTrace implementation is useful, though it could perhaps be moved to the contrib repo. Otherwise +1.

It's useful, that's for sure, so it would stay. I mostly meant the httptrace.go part.

The existing plugins are used in the examples, so rewriting the examples to use the propagation package directly would be in order.