When sending an event asynchronously, the original context used for
whatever generated the event (probably a synchronous, quick HTTP
context) is probably not what is wanted for sending the event, which
could face delays if a consumer is backed up.
I will admit myself to sometimes having "context blindness", where
I just take whatever context is incoming in a function and thread it
out to all calls. Normally this is the right thing to do when, say,
tying downstream API calls to an upstream HTTP timeout.
When making KV events, for example, we used the HTTP context for
`SendEvent()`, and this can cause the events to be dropped if they
aren't taken from the channel before the HTTP request finishes.
In retrospect, it was probably unnecessary to include a context in
the `SendEvent` interface.
We keep the context in place for backwards compability, but also in
case we want to use it for purposes other than timeouts and
cancellations in the future.
Co-authored-by: Christopher Swenson <christopher.swenson@hashicorp.com>
f4453384cb