fix: ensure push notification processor is never nil in newConn

- Add nil check in newConn to create VoidPushNotificationProcessor when needed
- Fix tests to use Protocol 2 for disabled push notification scenarios
- Prevent nil pointer dereference in transaction and connection contexts
- Ensure consistent behavior across all connection creation paths

The panic was occurring because newConn could create connections with nil
pushProcessor when options didn't have a processor set. Now we always
ensure a processor exists (real or void) to maintain the 'never nil' guarantee.

redis.go

@@ -970,8 +970,13 @@ func newConn(opt *Options, connPool pool.Pooler, parentHooks *hooksMixin) *Conn
 		c.hooksMixin = parentHooks.clone()
 	}
 
-	// Set push notification processor from options (always available now)
-	c.pushProcessor = opt.PushNotificationProcessor
+	// Set push notification processor from options, ensure it's never nil
+	if opt.PushNotificationProcessor != nil {
+		c.pushProcessor = opt.PushNotificationProcessor
+	} else {
+		// Create a void processor if none provided to ensure we never have nil
+		c.pushProcessor = NewVoidPushNotificationProcessor()
+	}
 
 	c.cmdable = c.Process
 	c.statefulCmdable = c.Process