This is a cleanup suggested by @andreimatei in the context of #72912 and #73940 .

The "eventLog" functionality in AmbientContext is a special-purpose recording mechanism that has its own dedicated debug page in /debug/events.

As of this writing, this mechanism is only used in the gossip package.

It was designed and implemented before we had created our tracing API, and has become redundant with it. In the new architecture, all components use the general-purpose tracing API. If we want to view only a subset of the events, we can then create a debug page which operates with a filter on the recorded traces.

Quoth Andrei:

the event log drives the /debug/events page. It's pretty similar to /debug/requests, which is driven by net/trace. The page allows you to expand one of these logs and see all the messages printed in it.
I think we should get rid of it because I bet nobody's used the gossip log in a long time (probably very few people even know about it), and because this functionality overlaps with our trace recordings. I'm trying to get tracing to be the one answer for all your... tracing needs. In fact I'm currently working on a UI for the span registry similar to these /debug/{requests/events} pages.

What I'm trying to do once the active spans registry goes live (which is quite close I think), is give people some ways of exploring the info in it. The initial thing will be a web page that has the same feel as /debug/{requests,events}, listing all the traces/spans that are currently open. I also want this page to let you filter by different things (at the very least by span name). For a given span, you should be able to find the other spans from its trace and, if the span has been recording, you should be able to see all the events in it.
The gossip event log functionality would be replaced by giving the respective gossip task a long-running recording span, which should perennially be part of the active spans registry.

Jira issue: CRDB-12020