Optimize the logic of "no blaze campaign" local notification

[irfano]

Closes: #12574

Description

The current logic is not optimal as it schedules the same notification multiple times and does not effectively handle evergreen notifications. This PR updates the logic based on the flowchart below:

Steps to reproduce

Each time a new campaign list is fetched, the logic for scheduling the reminder is triggered. I won’t provide specific testing instructions. Please test it on your own and check Local notification canceled: blaze_no_campaign_reminder and Local notification scheduled: type=blaze_no_campaign_reminder, delay=2592000000MILLISECONDS logs to verify the scheduled notifications. You don’t need to test the actual notification, as it’s outside the scope of this PR.

Testing information

Please test by adding endless and limited campaigns, and removing them.

The tests that have been performed

I tested each step in the flowchart by checking logs.

• I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on big (tablet) and small (phone) in case of UI changes, and no regressions are added.

[dangermattic]

	1 Warning
⚠️	This PR is assigned to the milestone 20.4. This milestone is due in less than 2 days. Please make sure to get it merged by then or assign it to a milestone with a later deadline.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	9dd620f
	Direct Download	woocommerce-wear-prototype-build-pr12585-9dd620f.apk

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Commit	9dd620f
	Direct Download	woocommerce-prototype-build-pr12585-9dd620f.apk

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 40.90909% with 26 lines in your changes missing coverage. Please review.

Project coverage is 40.60%. Comparing base (2820a5b) to head (08d8b96).

Files with missing lines	Patch %	Lines
...id/ui/blaze/notification/BlazeCampaignsObserver.kt	69.23%	2 Missing and 6 partials ⚠️
.../notifications/local/LocalNotificationScheduler.kt	0.00%	7 Missing ⚠️
...rc/main/kotlin/com/woocommerce/android/AppPrefs.kt	0.00%	6 Missing ⚠️
.../kotlin/com/woocommerce/android/AppPrefsWrapper.kt	0.00%	4 Missing ⚠️
...oid/notifications/local/LocalNotificationWorker.kt	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk   #12585      +/-   ##
============================================
- Coverage     40.60%   40.60%   -0.01%     
- Complexity     5671     5676       +5     
============================================
  Files          1228     1228              
  Lines         69025    69062      +37     
  Branches       9562     9569       +7     
============================================
+ Hits          28028    28043      +15     
- Misses        38420    38438      +18     
- Partials       2577     2581       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JorgeMucientes]

Excellent job @irfano! In all my test scheduling and cancelling happened as expected. Code looks good too!
Ready to ship. (I'm approving but leaving the merge up to you in case you want to apply the suggestion)

[JorgeMucientes]

Just a minor suggestion. No need to apply.

Wdyt of converting/rounding this milliseconds to DAYS and use DAYS as delayUnit for this. Makes debugging and checking the logs easier.

[irfano]

Good advice! However, while I’m confident it would work, it’s still an extra calculation that may result in rounding by ±1 day. I won't add it just for debugging purposes and will stay on the safe side.