0034 message tracing

[ianco]

Discussion points from the Aires call today (April 8), for posterity:

Trace decorator:

• whether the agent chooses to log trace events to the given "target" should be optional, i.e. the Agent can choose whether to log to the requested target, or to the pre-configured target (asking for trace events in this manner represents a potential data leak)
• I believe "full_trace" should always be "true" and is therefore redundant (if tracing is requested on a message or exchange you will always want the full scope of trace events)

Trace Report:

• added "thread_id", I believe this should always be provided if possible (or can be left blank if not available)
• added two versions of timestamp (epoch seconds and human-readable date/time) (note that when we use fluentd as a "target" it adds its own timestamp of when the event was received)
• added may the sequential suffix on "msg_id" (“... in the form X.1, X.2, X.3”) - didn't think this was necessary, as the "thread_id" provides correlation and fluentd provides a central timestamp) - so made it an optional feature Agents can choose to implement (with aca-py I don't think the additional effort is warranted)

[dhh1128]

I feel like this PR combines some excellent improvements with some undesirable shifts in the intent of tracing. I would like to tease them apart in an interactive discussion. Can we talk further before the PR moves forward as a unit?

[ianco]

@dhh1128 for sure. Do you know who else has implemented tracing (or is planning to)? They should be involved in any discussions of this rfc.

[TelegramSam]

Discussed 20241009. Has been built into ACA-Py.