feat: [SDK-5193] let an app opt out of subscription ID copy in Info.plist

[nan-li]

Description

One Line Summary

Lets an app turn off subscription ID copy with an Info.plist key.

Details

Motivation

The gesture in #1730 is on by default, and the only switch is OneSignal's remote kill switch. An app that doesn't want a pasteboard write in production should be able to say so itself, in its own Info.plist, without a support ticket.

Ticket SDK-5193. Follows #1730, which merged as c23c6f9; this PR targets main.

Scope

OneSignal_disable_subscription_id_copy set to YES in Info.plist

• read like the SDK's older Info.plist switches (OneSignal_disable_swizzling, OneSignal_suppress_launch_urls, OneSignal_disable_badge_clearing): a Boolean or Number counts by value and a String through NSString.boolValue, so <true/> and <string>YES</string> both opt out. That matters because Xcode's plist editor stores a new row as a String unless its type is changed. A missing or mistyped value leaves the gesture on instead of crashing on boolValue the way the Objective-C reads would.
• checked before the observers register. With the key set the detector registers nothing, so nothing is counted, written or recorded.
• That is stricter than the remote kill switch, which still records disabled so we can count attempts; an app that opted out has said no.
• One INFO line at start says the key was honoured, so a developer can confirm it took. The started latch still flips, so the recovery path's second start() stays quiet.
• The key names the outcome, not the gesture, so the docs can call the feature one thing.
• No public API, so the wrapper SDKs expose it with no change.

Other

The docs page and release notes need to say the feature is on by default and name the key.

Testing

Unit testing

OSDeviceGestureDetectorTests injects the opt-out and asserts, through the observer-counting center, that no observers register, that six cycles write nothing and record nothing, and that a second start registers nothing either. OSDeviceGestureDetectorInfoPlistTests deserialises each Info.plist value shape from its literal XML and checks the parse: <true/>, <integer>1</integer>, <real>1.0</real> and the strings YES, yes, true and 1 opt out; <false/>, <integer>0</integer> and the strings NO, false, 0 and empty do not; nil, array, dict, date and data values leave the gesture on. The parse tests fail against the previous NSNumber-only read. 187 OneSignalOSCore tests pass serially, SwiftLint clean apart from the pre-existing file length warning on the test file.

Manual testing

Not run on a device. The read is the same Bundle.main lookup the other Info.plist switches use.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

[fadi-george]

Potential issues:

• The Info.plist value is cast only to NSNumber, so string values like YES silently fail and leave copying enabled. Could we support NSString.boolValue too and add coverage for string-backed values?

[nan-li]

Potential issues:

• The Info.plist value is cast only to NSNumber, so string values like YES silently fail and leave copying enabled. Could we support NSString.boolValue too and add coverage for string-backed values?

good find, in 1c7d2d4 String now goes through boolValue like the other keys, with the plist-XML-driven tests in OSDeviceGestureDetectorInfoPlistTests.

[fadi-george]

My bad, I accidentally merged.

[nan-li]

My bad, I accidentally merged.

No probs! thanks for approving