fix special grpc metadata handling

[ktalg]

fix #700

There is a bug in the current handling of special grpc metadata (user-agent,host):
The MD itself is modified in the Dial method so that other threads cannot read the original MD while establishing a connection

Modifications to the MD are now moved outside of the Dial and need to be called separately when the request is sent

[codecov]

Codecov Report

Base: 89.0% // Head: 89.0% // Increases project coverage by +0.0% 🎉

Coverage data is based on head (e016ae0) compared to base (7de742f).
Patch coverage: 100.0% of modified lines in pull request are covered.

Additional details and impacted files

@@          Coverage Diff           @@
##           master    #697   +/-   ##
======================================
  Coverage    89.0%   89.0%           
======================================
  Files          30      30           
  Lines        4448    4454    +6     
======================================
+ Hits         3958    3964    +6     
  Misses        324     324           
  Partials      166     166           

Impacted Files	Coverage Δ
fgrpc/grpcrunner.go	90.7% <100.0%> (+0.2%)	⬆️
fgrpc/pingsrv.go	89.9% <100.0%> (+0.2%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[ldemailly]

Hi @ktalg how does the issue show up? (grpc run - missing headers in some? do you have a human visible repro?)

[ldemailly]

I'm testing a variant with setting things only once

[ldemailly]

(though I'm kinda approving my own changes too so KT ptal)

[ktalg]

@ldemailly and how about improving the name of extractDialOptions, because it does two things

[ldemailly]

@ldemailly and how about improving the name of extractDialOptions, because it does two things

yes that's a good point. will change it. code wise though, thoughts/ok?

[ldemailly]

oh you did already, cool

[ktalg]

@ldemailly and how about improving the name of extractDialOptions, because it does two things

yes that's a good point. will change it. code wise though, thoughts/ok?

I think our changes are good enough, there's nothing more to suggest!

But I seem to have violated 'DRY' in some places, and I think I should avoid these if there is a big refactoring in the future

[ldemailly]

thx we can further cleanup in #681 (repeat in tests is somewhat fine btw)