feat: Experimental features settings

[dcalhoun]

Expose select experimental features for users, allowing for user feedback.

Closes https://github.com/Automattic/dotcom-forge/issues/9730.

Screenshot


Screen recording

To Test:

1 - Toggle experimental features

1. Navigate to Me → App Settings → Experimental features.
2. Toggle the experimental editor features.
3. Open the post editor.
4. Verify the correct editor is utilized.

2 - Experimental features sync with remote feature flag UI

1. Navigate to Me → App Settings → Experimental features.
2. Toggle the experimental editor features.
3. Navigate to Me → Debug settings.
4. Verify the remote feature flags match the toggled experimental features.

Regression Notes

1. Potential unintended areas of impact
   • App settings
   • Remote feature flags
2. What I did to test those areas of impact (or what existing automated tests I relied on)
   • Manually tested navigating and editing various App settings screens.
   • Manually tested remote feature flags.
3. What automated tests I added (or what prevented me from doing so) Deemed unnecessary for the experimental features.

PR Submission Checklist:

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

Testing Checklist (strike-out the not-applying and unnecessary ones):

• [ ] WordPress.com sites and self-hosted Jetpack sites.
• [ ] 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]

	2 Warnings
:warning:	strings.xml files should only be updated on release branches, when the translations are downloaded by our automation.
:warning:	PR is not assigned to a milestone.

Generated by :no_entry_sign: Danger

[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	pr21459-e4838b2
	Commit	e4838b247ad756333df38820a9e5947b6dfc0335
	Direct Download	jetpack-prototype-build-pr21459-e4838b2.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	pr21459-e4838b2
	Commit	e4838b247ad756333df38820a9e5947b6dfc0335
	Direct Download	wordpress-prototype-build-pr21459-e4838b2.apk

Note: Google Login is not supported on these builds.

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 39.50%. Comparing base (acb4a47) to head (e4838b2). Report is 35 commits behind head on trunk.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## trunk #21459 +/- ## ======================================= Coverage 39.50% 39.50% ======================================= Files 2119 2119 Lines 99437 99437 Branches 15282 15282 ======================================= Hits 39281 39281 Misses 56674 56674 Partials 3482 3482 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[nbradbury]

I opted to build an implementation similar to the Privacy settings, relying upon the existing Java rather than building a new Kotlin view. I welcome any feedback on the approach.

I think this is fine.

[nbradbury]

@dcalhoun This looks good to me. I do think it's a bid odd to have "Debug settings" on the Me tab but "Experimental features" on the App Settings screen. To me they should be together on App Settings since they're related.

That's not something that has to be done in this PR, just wanted to get your thoughts on that.

[dcalhoun]

I do think it's a bid odd to have "Debug settings" on the Me tab but "Experimental features" on the App Settings screen. To me they should be together on App Settings since they're related.

@nbradbury understandable, I agree their separation is odd and I paused to consider this during implementation. Ultimately, I placed Experimental features based on the iOS implementation, where it resides beneath App settings. In contrast to Android, iOS places Debug beneath App Settings, so both Experimental Features and Debug reside next to one another.

I will also note that Debug is not visible to users, it is only present in non-production builds.

I'm open to relocating Experimental features in a separate PR, if that is preferred.

[nbradbury]

I would prefer to see those both under App Settings. I do realize Debug settings isn't seen by users, but if we keep these two in different places I believe it will always bug me :)