V5 resolve request permission

[nan-li]

Description

One Line Summary

Resolve the correct boolean for the requestPermission method when permission denied, and resolve correctly if permission is already granted.

Details

Resolve correct boolean when permission denied

• We were only resolving the call when r.getData() is true. This meant we only resolved when the prompt receives an accept response.
• Instead r.getData() itself is the response to the Promise

Resolve request permission call when permission already exists

Problem:
If permission is already enabled, the native call to OneSignal.getNotifications().requestPermission(fallbackToSettings, Continue.with(...) never suspends and the Continuation code block never runs. As a result, we would not be able to resolve the promise over the bridge.

Solution:
Before calling that method, do a permission check and return true early.

Motivation

Resolve calls to request permission correctly so app code doesn't hang.

Testing

Unit testing

None

Manual testing

Android emulator API 33

• Tested the boolean returned when permission is accepted and denied and it returns true and false respectively.
• Tested combinations of toggling permissions in app settings and calls to requestPermission.

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
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• 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.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is