Fix panic in otelhttptrace

[Alkorin]

Wait100Continue trace event is sent here before "http.receive" phase which results with a panic

Wait100Continue is called here : https://cs.opensource.google/go/go/+/refs/tags/go1.20.4:src/net/http/request.go;l=688 while "http.receive" phase is started in the defer here : https://cs.opensource.google/go/go/+/refs/tags/go1.20.4:src/net/http/request.go;l=559

Thus, the span grab here : https://github.com/open-telemetry/opentelemetry-go-contrib/blob/instrumentation/net/http/httptrace/otelhttptrace/example/v0.42.0/instrumentation/net/http/httptrace/otelhttptrace/clienttrace.go#L373 is nil and https://github.com/open-telemetry/opentelemetry-go-contrib/blob/instrumentation/net/http/httptrace/otelhttptrace/example/v0.42.0/instrumentation/net/http/httptrace/otelhttptrace/clienttrace.go#L375 panics

See reproducer at https://gist.github.com/Alkorin/ba749e56911d887d1acbf1de23604095

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Alkorin / name: Thomas Soëte (d42e293)

[pellared]

Can you please add test(s)?

[codecov]

Codecov Report

Merging #3892 (9ebb157) into main (ba7a210) will increase coverage by 0.0%.
The diff coverage is 100.0%.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #3892   +/-   ##
=====================================
  Coverage   79.3%   79.4%           
=====================================
  Files        165     165           
  Lines      10426   10426           
=====================================
+ Hits        8278    8284    +6     
+ Misses      2012    2006    -6     
  Partials     136     136           

Impacted Files	Coverage Δ
...on/net/http/httptrace/otelhttptrace/clienttrace.go	79.0% <100.0%> (+2.5%)	⬆️

[Alkorin]

Done

[pellared]

The test is flaky.

When I run go test -count=100 it always fails.
Personally, I would look into possible synchronization issues.
From https://pkg.go.dev/net/http/httptrace#ClientTrace:

Functions may be called concurrently from different goroutines and some may be called after the request has completed or failed.

(Not directly related to this PR). If I understand this correctly it may even mean that the current implementation may contain logical race conditions as I do not see how activeHooks synchronizes multiple concurrent HTTP requests.

[Alkorin]

True, the lock on https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/net/http/httptrace/otelhttptrace/clienttrace.go#L235 may introduce a context switch and the span is recorded after the end of the request.

Test updated

[pellared]

Thank you for your contribution 👍

I updated the changelog.