Example refactor of goldmane

[Brian-McM]

Description

High level over view:

• Create a clear separation of what's basically the datastore (bucket_ring) from the aggregator
• • I found it difficult to navigate the aggregator and the bucket ring, so I moved it towards a model where the buckets and eventually the diachronics would be more or less hidden from view
• • You'll besically just query the bucket ring saying give me flows for this time range, or give me flows for this set of time ranges (where a single flow key might be aggregated on different windows)
• With the above, it's helped remove the secondary "window" storage that's in the diachronics, just tying the diachronic, bucket, and bucket ring together (they're already extremely tightly intertwined, this just helps make that clear without duplicating types)
• • I'm thinking in another iteration on this I might be able to remove the need for the diachronic type in general, there's not much in it right now and the functions on the bucket ring are all moving towards just iterating over the flows / keys.
• I've essentially removed bucket index referencing from the aggregator, so you query the bucket ring solely based on time.
• The sink and streaming logic was push back to the aggregator and I just used a flat time stored in the aggregator to mark when an emission or stream was last successful. This seemed to simplify things since we stream and emit the buckets in order so you don't need to store "Pushed" in every bucket.
• The "default" index was removed, because it's not really an index and doesn't actually implement the interface (so just a level of indirection that was a bit confusing).

The generics that are there could either be simplified or removed (it's incomplete right now). They're not there necessarily for reusability, but more to help define the boundary between the bucket ring and aggregator / other types (emitter, streamer).

Related issues/PRs

Todos

• Tests
• Documentation
• Release note

Release Note

TBD

Reminder for the reviewer

Make sure that this PR has the correct labels and milestone set.

Every PR needs one docs-* label.

• docs-pr-required: This change requires a change to the documentation that has not been completed yet.
• docs-completed: This change has all necessary documentation completed.
• docs-not-required: This change has no user-facing impact and requires no docs.

Every PR needs one release-note-* label.

• release-note-required: This PR has user-facing changes. Most PRs should have this label.
• release-note-not-required: This PR has no user-facing changes.

Other optional labels:

• cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.
• needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.