Bug: Resolve bug that is possibly preventing trace ID propagation on viewing donations

[pattishin]

Full context from @ace-n: Update: I tried to get trace ID propagation working for both POST /donate and GET /viewDonations. I was able to specify the X-Cloud-Trace-Context header in the response, but this has no effect on the request's actual trace ID (as recorded by Cloud Logging).

Related PR: #620

[grayside]

I responded to this comment in the PR. I believe this problem is rooted in a misinterpretation that we're trying to set a trace ID in a response, as opposed to extract the request trace ID and make it available for frontend UI building.

[ace-n]

There are two requests here:

1. a POST to /donate to submit the donation
2. a GET [redirect] to /viewDonation to view the resulting donation

Currently, #620 only shows the first request (POST /donate) and omits the second (GET /viewDonation).

---

We could call this intended behavior, but I'm assuming our end-users would prefer to see the entire request chain.

[grayside]

Interesting, so the issue here is that by using a redirect in donate, we are splitting the full transaction. In a more dynamic UI, we would maybe get the confirmation without leaving the page and viewDonation would be outside this journey.

[muncus]

Trace data is really not designed to be reused between requests. It is possible to do this by having the frontend generate trace IDs to send with multiple requests, but I've only heard of that approach being taken with native (non-web) apps. (i'm also not sure that all trace backends would support non-overlapping spans).

Generally, i'd discourage any manual manipulation of trace headers, and let the OTel SDK do that for us, but i suppose that ball is already in my court 😅