Migrate metrics agent layer to Struct API and bullet Stream

[runesoerensen]

Migrate metrics agent layer to Struct API and bullet Stream. Taking over from #320 with a smaller and more modular process.

[schneems]

I looked at all the commits. They're easy to follow in isolation. You were right. It was quite easy to review.

I left one comment about why I left some code in that seemingly did nothing, it was intentional. Basically I'm being defensive about guarding against possible breaking future modifications. I'm curious if that description makes sense and your thoughts on the relative costs/benefits.

[schneems]

I think it makes sense to keep iterating. I did some work on top for this layer then I'm pretty happy with it #322. And then I want to move over to porting other layers, basically re-doing the work of #320 in this style if that's agreeable.

[runesoerensen]

To be honest, I should probably not have included e0733ed on this branch. I wrote each commit as examples of focused types of changes that could be reviewed/integrated/merged better and faster independently (as separate PRs), and ended up confusing that by opening a PR including all the changes. To walk through my thought process (and noting things I could've done better in hindsight/based on your review):

1. 6af2837 would be the first commit (or PR, particularly if the same migration was applied to all the layers in a series of commits like https://github.com/heroku/buildpacks-jvm/pull/721/commits), along with e344c82 (bumping libcnb.rs to 0.23.0).

   If I had opened a PR just bumping the libcnb version and migrating the metrics agent layer to the struct layer API, our lint checks would've prevented merging it and, among other things, forced me to make the changes required to allow using deprecated features (i.e. saving you from most of this work).

2. The following three commits e0733ed~3...e0733ed were not part of the code changes in Migrate to the Struct API and output via bullet_stream #320, or important to the end goal: Making the Ruby CNB's logging style consistent with our shared approach (in this case by adopting bullet_stream, facilitated by/necessitating the struct layer API migration). I still included them because of this comment in the original PR description:

   To minimize the change, I tried to avoid refactoring code as much as possible

   Which I totally get. Those commits were examples of "unrelated" code clean-up/maintenance/bug fixes I felt compelled to make while migrating to the struct layer API. They were "unnecessary" in the sense that the task could've been achieved without them, but not making these changes would also feel like a compromise, wasting the opportunity that revisiting code often presents.

   The good news is that we don't have to compromise and avoid such quick changes; introducing them in separate commits/PRs makes it extremely easy to review and integrate, and can help focus the conversation on the substance.

   Case in point, if each of these commits had been reviewed individually:

   • 167cbb8 was a straightforward bug fix/improvement that would take around 60 secs or less to review and approve.

   • 56004d7 introduced a cleaner Metadata struct, but could've been further improved after your review, to factor in the SPOT considerations here.

   • e0733ed would have lead to this highly relevant comment (that lead me to write this response), but specifically related to that part alone. That being said, it'd definitely have been better if I had introduced this particular change after migrating to bullet_stream.

     As you can see from my commit message, I was very much open to the possibility that I was missing something obvious - and the change would at best have zero functional impact. By making the change before the bullet_stream commit, I unnecessarily made it more difficult to discard in case it didn't pass code review (as rebasing/merging without that commit would've caused conflicts).

3. Finally, my last commit (migrating to bullet_stream) would actually have benefitted from the first PR/commit described above (in particular, passing all the lints). When I committed that change, I had hundreds of clippy deprecation warnings - so I disregarded them, causing me to the miss the ones that actually mattered here (which you fixed in this commit).

I've talked a lot about PRs here, but hope it's also clear what I really care about: Clean, focused, atomic commits, that are able to stand on its own (e.g. be reviewed and tested independently, without introducing regressions) and make just one type of change (and never more than one logical change). GitHub PRs can be a great tool in that effort, not least because they trigger CI workflows that can help during development. But as far as I'm concerned, if the commits make sense on their own, you can basically structure them however you like in PRs.

At any rate: Sounds like you want to iterate based on this branch -- I've approved the two PRs building on it, but haven't merged anything. Feel free to proceed however you prefer :)