Use Case

As a user of the driver,
I want driver events that can be emitted in multiple places to contain information about the cause of the event,
So that I can determine the cause of a given event without cross referencing other driver events and state when debugging.

Some driver non-error events can be emitted from multiple locations.  `TopologyDescriptionChangedEvent`s, for example can be emitted when the client connects, as a response to a server heartbeat event, or as a response to srv polling events.  There is currently no information on the event that indicates the cause or location in the driver this event was emitted from.  As an example, if the topology changed event had a field `reason` that could be "topology connected | heartbeat processed with new servers | srv polling detected new servers", it would be much easier to track down the cause of certain events when debugging using driver events.

Error events could also benefit from more information, but they already contain some clue as to why there were created (they contain errors with stacktraces).  

User Impact

• What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?

Dependencies

• upstream and/or downstream requirements and timelines to bear in mind

Unknowns

• questions that need to be answered to determine implementation

Acceptance Criteria

Implementation Requirements

• functional reqs, potential snafus to avoid, performance targets, etc

Testing Requirements

• unit test, spec test sync, etc

Documentation Requirements

• DOCSP ticket, API docs, etc

Follow Up Requirements

• additional tickets to file, required releases, etc