Add prof.log metrics to telemetry

Here's some information the logs that are generated in prof.log:

At first call:

[ ] Write out command line and all arguments
- Does it makes sense to provide this as part of a metric? We have a summary metric that has version information and such in it. It could be added to that.
Store the current memory, current time, user time used and system time used

Logs:

[x] Total memory, total memory change since last call, and current malloced memory
- Some of this is already provided as part of the process metrics, or can be calculated from the differences between reports.
[x] Time changes against the values stored on first run
[x] Session stats (these are already stored as metric values, and returned from their counters)
[x] Total and current number of connections
[x] Current number of sessions
[x] TCPStats, stored in static TCPStateStats object returned by TCPAnalyzer::GetStats()
- Good candidate for replacing with telemetry framework. Stats are already set via calls into the state object from other places in code, so would just take adapting to the telemetry framework instead.
[x] Number of connections killed by inactivity, updated by the Session code into a global value zeek::detail::killed_by_inactivity
- This one might be hard to remove since it’s referenced from script land also
[x] DNS stats, returned by DNS_Mgr::GetStats()
- Good candidate for replacing with telemetry framework, but will need some rework to set the stats in appropriate places
[x] Trigger stats, returned by Trigger::Manager::GetStats()
- Good candidate for replacing with telemetry framework, but will need some rework to set the stats in appropriate places
[x] Number of timers by type, returned by TimerMgr::CurrentTimers()
- CurrentTimers() returns an array of timers by type, and the setting of those values happens where timers are managed. This could easily be adapted to the telemetry framework.
[x] Number of current timers, peak number of timers, lag time between current time and last timer to be processed
[x] Number of open threads, returned by threading::Manager::NumThreads()
- Easy value to update as threads come and go
[x] Statistics about each individual open thread
- This one may be more tricky to manage, but assuming the threads can talk to the telemetry manager themselves it could be doable. The individual threads will have a block of metrics for each one.
[x] Statistics about the broker manager
- Good candidate for replacing with the telemetry framework, as the broker manager knows all of this information and can update the metrics values as they change

“Expensive” Logs:

[ ] Statistics about the rule matcher: The number of matchers, NFA states, DFA states, computed matches, and memory usage
- It should be possible for the rule matcher to update these values automatically, but it might be fairly expensive depending on how often they change.
[ ] Statistics about the size of each individual global table in script land, assuming the table either has 100 entries or has 100 recursive entries.
- This would need a separate thread to request this information periodically, because we’re not going to update a metrics value every time a table changes size. That’s not to say it couldn’t be the same thread that’s currently updating the statistics.
- This could be handled by a callback instrument, where we just update the instrument whenever Prometheus requests it.

zeek / zeek

Add prof.log metrics to telemetry #3081