[Reader] Implement analytics events considering new filter UI

[RenanLukas]

Fixes #19925

---

To Test:

1 - Install JP and sign in
2 - Open Reader
3 - Select Subscriptions in the drop-down menu
4 - Tap the blogs chip: the following event should be tracked with the new parameter "source":

🔵 Tracked: reader_filter_sheet_displayed, Properties: {"source":"blogs"}

5 - Dismiss the blogs chip and tap the tags chip: the following event should be tracked with the new parameter "source":

🔵 Tracked: reader_filter_sheet_displayed, Properties: {"source":"tags"}

6 - Tap any tag in the bottom sheet: the following event should be tracked:

🔵 Tracked: reader_filter_sheet_item_selected

7- Tap "x" to clear the filter: the following even should be tracked:

🔵 Tracked: reader_filter_sheet_cleared

8- You should NOT see reader_filter_sheet_item_selected being tracked when the filter is cleared;
9 - Repeat steps 6-8 using a blog instead of tag.

---

Regression Notes

1. Potential unintended areas of impact

   • Existing analytics events not being triggered

2. What I did to test those areas of impact (or what existing automated tests I relied on)

   • Manual testing and updated unit tests.

3. What automated tests I added (or what prevented me from doing so)

   • Updated SubFilterViewModelTest.

---

PR Submission Checklist:

• I have completed the Regression Notes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

---

UI Changes Testing Checklist:

• Portrait and landscape orientations.
• Light and dark modes.
• Fonts: Larger, smaller and bold text.
• High contrast.
• Talkback.
• Languages with large words or with letters/accents not frequently used in English.
• Right-to-left languages. (Even if translation isn’t complete, formatting should still respect the right-to-left layout)
• Large and small screen sizes. (Tablet and smaller phones)
• Multi-tasking: Split screen and Pop-up view. (Android 10 or higher)

[dangermattic]

	1 Warning
⚠️	PR is not assigned to a milestone.

Generated by 🚫 Danger

[wpmobilebot]

Found 1 violations:

The PR caused the following dependency changes:

+\--- me.saket.cascade:cascade-compose:2.3.0
+     +--- androidx.activity:activity-compose:1.7.2 -> 1.8.0 (*)
+     +--- androidx.compose.ui:ui:1.5.2 -> 1.5.3 (*)
+     +--- androidx.compose.ui:ui-tooling:1.5.2 -> 1.5.3 (*)
+     +--- androidx.compose.foundation:foundation:1.5.2 -> 1.5.3 (*)
+     +--- androidx.compose.material3:material3:1.1.2 (*)
+     \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.9.10 (*)

Please review and act accordingly

[wpmobilebot]

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

	App Name	Jetpack
	Flavor	Jalapeno
	Build Type	Debug
	Version	pr19929-45bd9fb
	Commit	45bd9fb
	Direct Download	jetpack-prototype-build-pr19929-45bd9fb.apk

Note: Google Login is not supported on these builds.

[wpmobilebot]

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

	App Name	WordPress
	Flavor	Jalapeno
	Build Type	Debug
	Version	pr19929-45bd9fb
	Commit	45bd9fb
	Direct Download	wordpress-prototype-build-pr19929-45bd9fb.apk

Note: Google Login is not supported on these builds.

[daniloercoli]

Looks good to me! There are a couple of warnings, but once they're fixed, we can proceed with shipping it.

[RenanLukas]

Thanks for the review, @daniloercoli

Since we're working in a feature branch I usually don't assign the PRs to a milestone, and instead only the feature branch PR when we open it. The reason for that is because AFAIU apps infrastructure team uses the milestone to understand which PRs are part the new version. If we, for example, add the next version milestone (let's say 24.1) to all the PRs related to this feature but then we decide to delay the delivery to 24.2 these PRs will have the 24.1 milestone but in fact they won't be in trunk yet, since they're in the feature branch.

TL;DR I don't usually assign a milestone for PRs not targeting trunk, but let me know if you have another opinion.

We call this one a violation but in fact this is the expected message whenever there's a dependency change (e.g. adding a new library or bumping a dependency version). That being said, I have no idea why I'm getting this message in this PR because as far as I can see I'm not changing any dependency version. 🤔 I'll try to figure out what's happening.

[RenanLukas]

@daniloercoli I think I got it: initially I was targeting trunk with this PR, and when I realized I had the wrong base branch I've changed it to feature/reader-ia. The me.saket.cascade:cascade-compose:2.3.0 was added in our feature branch, so it would make sense to have this warning when targeting trunk so I believe this warning is being shown because of that. After I changed the target to feature/reader-ia it doesn't make sense anymore, but it seems like it doesn't get deleted.

[daniloercoli]

LGTM!