Set the baggage even when the trace id is not successfully extracted

[joegoldman2]

Fixes #50158.

Better to review it without whitespace diff: https://github.com/dotnet/aspnetcore/pull/55341/files?diff=unified&w=1.

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

[dotnet-policy-service]

Thanks for your PR, @joegoldman2. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[amcasey]

Some basic questions.

[amcasey]

Not having a request id here exercises the new code (thanks!), but is it something that could plausibly happen? This question may be terribly naive - I'm not very familiar with distributed tracing.

[joegoldman2]

Yes it's possible. Not all frameworks set it. This is not the case with .NET because HttpClient sets it (https://github.com/dotnet/runtime/blob/33a68d0cef067034df5cbac89415568e5fda63ce/src/libraries/System.Net.Http/src/System/Net/Http/DiagnosticsHandler.cs#L308) but someone can use another framework (or make the request manually via curl, Postman, or whatever) and in this case there will be no request id (traceparent) in the request (ASP.NET will generate one in this case).

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.