[CAE-1088] feat: RESP3 notifications support

[ndyakov]

This PR adds RESP3 push notifications support, enabling clients to handle server-initiated messages beyond traditional request-response patterns. The handlers for the notifications can be registered and deregistered by the end user. Added a special protected flag when registering a handler, so internal important handlers cannot be deregistered ( hitless upgrades will probably use this ).

Please review thoroughly. This is going to be executed as part of each read from connection and it is important it is performant both when there is a push notification to be processed and when there isn't one.

notes:

• - still can refactor error handling a bit.
• - should look at better timeout for checking the push notifications.

[htemelski-redis]

Looks good.
Do we have benchmarks about the introduced overhead when we support the push notifications?

[ndyakov]

Looks good. Do we have benchmarks about the introduced overhead when we support the push notifications?

I was hoping we can use the benchmark application you were working on. I don't have other benchmarks. If we find it more than expected, I do think we can use something similar to how connCheck is peeking in the buffer. Reviewing this approach reveled a bug that the current implementation has, which is the connCheck will read a byte from the fd instead of just peeking. Let me fix this before finally approving this.

[Copilot]

Pull Request Overview

This PR implements RESP3 push notifications support for the Redis Go client, enabling handling of server-initiated messages beyond traditional request-response patterns. The implementation includes a processor-based architecture for registering handlers with protection flags and optimized performance for both notification processing and normal operations.

Key changes include:

• Addition of push notification processing with processor pattern and handler registry
• Integration of push notification checks throughout client operations (command execution, pipelines, transactions)
• Performance optimizations for RESP3 connections with buffered data detection

Reviewed Changes

Copilot reviewed 22 out of 22 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
push/processor.go	Core notification processor with handler registry and notification processing logic
push/registry.go	Handler registry with protection mechanism for critical handlers
redis.go	Integration of push notification processing into base client operations
options.go	Addition of push notification processor configuration option
internal/proto/reader.go	RESP3 push notification name peeking functionality
internal/pool/pool.go	Connection pool optimization for RESP3 push notification handling

Comments suppressed due to low confidence (2)

redis.go:108

• The 10 microsecond timeout is extremely short and may cause frequent timeouts on slower systems or under load. Consider using a more reasonable timeout like 1-5 milliseconds to ensure push notifications can be read reliably while still being non-blocking.

//		}

push/push_test.go:316

• This line incorrectly uses len(notificationName) twice - once for the length and once in place of data. It should be len(data) for the second parameter: fmt.Sprintf("$%d\r\n%s\r\n", len(data), data)

			t.Error("First handler should be registered correctly")