grpcsync: add ScheduleAndWait to CallbackSerializer

[Retr0-XD]

Description

Adds a ScheduleAndWait method to CallbackSerializer that schedules a callback and blocks until it has been executed.

This eliminates a repetitive pattern scattered throughout the codebase where callers create a done channel, close it inside the callback, and block on it:

// Before
done := make(chan struct{})
serializer.ScheduleOr(func(context.Context) {
    // Do stuff
    close(done)
}, func() {
    close(done)
})
<-done

// After
if err := serializer.ScheduleAndWait(func(ctx context.Context) {
    // Do stuff
}); err != nil {
    // handle ErrSerializerClosed
}

API

// ScheduleAndWait schedules the provided callback function f to be executed in
// the order it was added, and blocks until the callback has been executed. It
// returns nil once f has been run. If the context passed to
// NewCallbackSerializer was already canceled before this method is called, the
// callback will not be scheduled and ErrSerializerClosed is returned.
func (cs *CallbackSerializer) ScheduleAndWait(f func(ctx context.Context)) error

// ErrSerializerClosed is returned by ScheduleAndWait when the callback cannot
// be scheduled because the serializer has already been closed.
var ErrSerializerClosed = errors.New(\"grpcsync: serializer closed before the callback could be scheduled\")

Tests added

• TestCallbackSerializer_ScheduleAndWait_Normal — happy path: callback executes and returns nil
• TestCallbackSerializer_ScheduleAndWait_Closed — serializer already shut down: returns ErrSerializerClosed
• TestCallbackSerializer_ScheduleAndWait_FIFO — FIFO ordering is preserved relative to TrySchedule
• TestCallbackSerializer_ScheduleAndWait_Concurrent — 50 concurrent callers all complete successfully

RELEASE NOTES:

• grpcsync: Add ScheduleAndWait method to CallbackSerializer for blocking callback execution

Fixes #8501

---

AI disclosure: GitHub Copilot was used during implementation and test writing. I fully understand all changes made in this PR.

[Retr0-XD]

Hi @dfawley @zasweq — would appreciate a review when you get a chance!

[Retr0-XD]

@Pranjali-2501 can you please review this PR :)

[Pranjali-2501]

@Retr0-XD , CI is failing. Please fix it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.00%. Comparing base (12e91dd) to head (f509f52).
⚠️ Report is 28 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8998      +/-   ##
==========================================
- Coverage   83.04%   83.00%   -0.05%     
==========================================
  Files         411      411              
  Lines       32892    32969      +77     
==========================================
+ Hits        27316    27365      +49     
- Misses       4181     4200      +19     
- Partials     1395     1404       +9     

Files with missing lines	Coverage Δ
internal/grpcsync/callback_serializer.go	100.00% <100.00%> (ø)

... and 34 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Retr0-XD]

Hi @Pranjali-2501 , CI fixed , the label is missing for PR validation check alone . Please review and let me know.

[Retr0-XD]

Let me know if anything else is required

[easwars]

What is the purpose of returning this new error sentinel given that this can fail only when the caller of this method cancels the context that they themselves passed to this method? Why not just return the error returned from Put as is.

[easwars]

Also, can you please merge master into your branch. That should take care of the failing vet-proto CI.

[easwars]

Nit: Can we use an atomic.Int instead?

[easwars]

Could you consider using WaitGroup.Go. This is the new ergonomic way of spawning goroutines and waiting on them to complete with a WaitGroup.

See: https://pkg.go.dev/sync#WaitGroup.Go