Feat: Add OneSignal push provider adapter (#7726)

[deepshekhardas]

No description provided.

[greptile-apps]

Greptile Summary

This PR adds a OneSignal push notification adapter that maps the shared PushMessage contract to the OneSignal REST API v1. Most fields (icon, color, tag, data, priority, contentAvailable, badge, image) are now correctly wired.

• The content_available guard uses !\is_null(...) instead of checking the boolean value, so an explicit contentAvailable: false still sends content_available: true to OneSignal, silently enabling background/silent push against the caller's intent.
• The ios_sound field unconditionally appends .wav to the caller-supplied sound name, which double-extends already-qualified filenames (e.g. chime.wav becomes chime.wav.wav) and corrupts values like default.

Confidence Score: 3/5

The adapter has a logic inversion in the content_available guard and a sound-name corruption on iOS that will silently misbehave for callers who set those fields.

The content_available condition accepts both true and false but always writes true to the payload, which flips silent-push behavior. Combined with the .wav double-extension issue on iOS sounds, two distinct field mappings produce incorrect output in normal usage scenarios.

src/Utopia/Messaging/Adapter/Push/OneSignal.php — the process() method has the incorrect null-check guard and the unconditional .wav suffix

Important Files Changed

Filename	Overview
src/Utopia/Messaging/Adapter/Push/OneSignal.php	New OneSignal push adapter; maps most PushMessage fields correctly but has a logic bug where an explicit contentAvailable: false still sends content_available: true to OneSignal
tests/Messaging/Adapter/Push/OneSignalTest.php	Minimal integration test wiring that extends the shared push Base test suite; straightforward and correct

_{Reviews (2): Last reviewed commit: "fix: add parent constructor, fix deliver..." | Re-trigger Greptile}

[greptile-apps]

Preserve silent pushes

The common Push message supports contentAvailable, and the shared push tests send data-only messages with contentAvailable: true. OneSignal requires content_available for background/data notifications, but this adapter only sends data, so callers using the silent push contract through OneSignal can get a normal or rejected notification instead of a background notification.

Suggested change

	if (!\is_null($message->getData())) {
	$payload['data'] = $message->getData();
	}
	if (!\is_null($message->getData())) {
	$payload['data'] = $message->getData();
	}
	if (!\is_null($message->getContentAvailable())) {
	$payload['content_available'] = $message->getContentAvailable();
	}

[greptile-apps]

Do not rewrite sounds

Other push adapters pass the message sound through unchanged, and callers may pass values like default or an already-qualified filename. Appending .wav here changes default to default.wav and chime.wav to chime.wav.wav, which can make iOS use the wrong sound or no custom sound at all.

Suggested change

	if (!\is_null($message->getSound())) {
	$payload['android_sound'] = $message->getSound();
	$payload['ios_sound'] = $message->getSound() . '.wav';
	}
	if (!\is_null($message->getSound())) {
	$payload['android_sound'] = $message->getSound();
	$payload['ios_sound'] = $message->getSound();
	}

[greptile-apps]

content_available condition inverts intent when explicitly set to false

The guard !\is_null($message->getContentAvailable()) is true for both true and false. If a caller explicitly constructs Push with contentAvailable: false, the adapter still writes 'content_available' => true into the payload, silently enabling silent/background push on OneSignal devices when the caller's intent was the opposite. The fix is to check the boolean value directly: if ($message->getContentAvailable()).