feat: EgressTrackingService

[volmedo]

Ref: #174

I separated the logic for storing receipt batching and the one sending those batches to the egress tracking service. Now the store just stores the batches, and notifies when they are ready. The new EgressTrackingService will invoke space/egress/track with new batches.

[frrist]

After seeing this used in practice here's an idea for the interface/design of the batch store, which I suggest we rename to "Journal":

type Journal interface {
    // Append adds an entry to the journal
    Append(ctx context.Context, entry []byte) error
    // List all completed (rotated) segments
    ListSegments(ctx context.Context) ([]SegmentInfo, error)
    // Get a completed segment by its CID
    GetSegment(ctx context.Context, cid cid.Cid) (io.ReadCloser, error)
    // Delete a segment by its CID
    DeleteSegment(ctx context.Context, cid cid.Cid) error
}

type SegmentInfo struct {
    CID         cid.Cid
    Size        int64
    EntryCount  int
    CreatedAt   time.Time
    FinishedAt  time.Time
}

// elsewhere....
journal := NewFSJournal(path, Options{
    MaxSize: 100*MB,
    OnRotation: func(ctx context.Context, segment SegmentInfo) error {
        // Queue for egress service
        return jobQueue.Enqueue(ctx, segment)
    },
})

Suggesting this with the goal of getting to a more generalized implementation.

Currently the Append operation forces the callers to deal with rollover/notification events, which they may not always want to do.

OnRotation defines the callback that fires when rotation happens (like Alans suggestion elsewhere). For the case at hand this means push it to the queue, but for other use cases this could be something else.

Once the job is processed from the queue, and the etracker becomes aware of it, it can then fetch the segment with GetSegment as we do now. Later, we can call (and implement) DeleteSegment for GC. ListSegments becomes our window for debugging/monitoring.

[frrist]

When it comes time to test, specifically around failure cases, we might want these to be configurable. see ReplicatorConfig for an example on how this has been done elsewhere.

[volmedo]

that is true when you are testing the job queue implementation. I just mocked the queue out in the service's tests.

I actually had a first implementation replicating ReplicatorConfig (sorry) and then I ditched it when I saw they values were hardcoded anyway. At least it is more explicit this way. It will be easy to expose these values in config when needed.

[volmedo]

thanks for the input @frrist. Again, I'm advocating against early generalization. I think getting this to work as soon as possible is more valuable at this stage of the project, and we can always iterate if needed without assuming extra risk/effort doing it then vs. doing it now.

[volmedo]

@frrist I want to merge this into #245 and I'd appreciate if you could take one final look and approve if you feel it's ready, or suggest more changes.

[frrist]

Let's get this merged into #245 and I'll leave any comments there