fix: dev server commands emit events

[mike-zorn]

This adds events for the dev server commands so that we can track adoption. Along the way, I also did the following

• Added a LogClient implementation for testing event tracking
• Simplified the TrackerFn so that it was easier to swap clients
• Split up the event tracker implementations into multiple files
• Added a note on what steps are needed to add a command because we missed 2/3 for the dev server.

Tested the event sending by swapping in LogClient and I produced the following (404 was expected)

❯ go run . dev-server add-project --project jimbo-jones --source staging
2024/08/28 15:48:12 SendCommandRunEvent, properties: map[action:add-project baseURI:https://app.ld.catamorphic.com flags:[access-token analytics-opt-out base-uri dev-stream-uri project source] name:dev-server]
unable to get SDK key from LD API: 404 Not Found (code: internal_server_error)
2024/08/28 15:48:12 SendCommandCompletedEvent, outcome: error

[dbolson]

I don't think this gets called for every subcommand, so running something like flags show test-flag doesn't send a "CLI Command Run" event, only a "CLI Command Completed."

It looks like the root's PersistentPreRun method isn't run for all subcommands.

[mike-zorn]

The docs indicate that PersistentPreRun does get run by sub commands (PreRun doesn't get run by sub commands). Were you observing different behavior? Could I achieve do the same thing by putting the run event command in the Execute method like we did for completed?

[dbolson]

If you print out the data sent to gonfalon in the analytics Client#sendEvent() method, you can see what gets sent. Or you could dump out the body gonfalon's POST /internal/tracking if that's easier. When I printed out the request body in main vs. the branch, I didn't see the first request show up in the latter.

You can try to get it working in Execute, but I think we tried that and it didn't have all the info or wasn't called all the time when it was expected. I can't remember exactly the issue, but you may find another solution if you want to spend more time with it.

[mike-zorn]

Turns out that this sorta works. Issue is that this doesn't get run for help commands. Other issue is that my annotation-based-event-properties idea has a lot of issues since the annotations are used for other reasons and will make it really hard to understand what event properties are significant.

I'm gonna abandon this approach and implement the event tracking more directly. Also, I'll add a note in CONTRIBUTING.md about the stuff you need to do when adding a new command since there are a few things you need to do for it to be wired up correctly.