feat: implement event tracking for worker_handler.go

[teslashibe]

Problem

We need to track who, what, and how work gets done on the protocol. This means we need real time indexed insight into the amount of work requests happening on the network, who is completing them, and what errors are occurring. We have implemented a lightweight package in this PR: https://github.com/masa-finance/masa-oracle/pull/513

We now need to implement this package in our codebase.

Acceptance criteria

The events we should track are as follows:

1. Work Distribution Event:

   • Track when work is distributed to a worker
   • Include information about whether it's a remote or local worker
   • Capture the work type and peer ID

2. Work Completion Event:

   • Record when a work item is successfully completed
   • Include the work type and peer ID
   • Add a flag indicating whether the work was successful

3. Worker Failure Event:

   • Log when a worker fails to complete a task
   • Include the work type, peer ID, and error message

4. Work Execution Start Event:

   • Track when work execution begins
   • Include the work type and whether it's a local or remote execution

5. Work Execution Timeout Event:

   • Record when work execution times out
   • Include the work type and the timeout duration

6. Remote Worker Connection Event:

   • Log when a connection is established with a remote worker
   • Include the remote worker's peer ID

7. Stream Creation Event:

   • Track when a new stream is created for communication with a remote worker
   • Include the remote worker's peer ID and the protocol used

8. Work Request Serialization Event:

   • Record when a work request is serialized for transmission
   • Include the work type and the size of the serialized data

9. Work Response Deserialization Event:

   • Log when a work response is deserialized after reception
   • Include the work type and whether deserialization was successful

10. Local Worker Fallback Event:

    • Track when the system falls back to using a local worker
    • Include the reason for fallback (e.g., no remote workers available, all remote workers failed)

[restevens402]

There was an issue with sending tracking for the local node because we were not populating the AddrsInfo for it. Adding that to the local solves the runtime error.

[mudler]

PR in #525