feat(feature-flag): enable runtime feature flag change

[rafaeltonholo]

Resolves #10102.
Depends on #10131

This PR introduces the capability to enable and disable feature flags during runtime execution via the Secret debug screen.

Changes summary

• Add new Secret Debug Section: Feature Flag
• Add MutableFeatureFlagFactory (Available only on Debug builds)
• Rename AccountSetupFinishedLauncher to MessageListLauncher

Screen Recording

Screen.Recording.2025-11-13.at.8.56.57.AM.mp4

[wmontwe]

I think the MutableFeatureFlagFactory mixes "define flags" and "mutate runtime overrides" in a way that feels hard to follow.

When the goal is that the factory defines the flags and their defaults while there is an optional runtime override, the best would be to keep "defaults" and "overrides" apart.

Rough idea:

interface FeatureFlagFactory {
    fun createCatalog(): List<FeatureFlag>
}

interface FeatureFlagOverrides {
    fun getAll(): Map<FeatureFlagKey, Boolean>
    fun get(key: FeatureFlagKey): Boolean?
    fun set(key: FeatureFlagKey, enabled: Boolean)
    fun clear(key: FeatureFlagKey)
    fun clearAll()
}

class InMemoryFeatureFlagProvider(
    private val factory: FeatureFlagFactory,
    private val overrides: FeatureFlagOverrides,
): FeatureFlagProvider {
    // cache defaults privately


    fun provide(key: FeatureFlagKey): FeatureFlagResult { 
        // answer from overrides first then fallback to defaults
    }
}

Then there could be a "in-memory" and a "no-op" version of FeatureFlagOverrides and injected based on the build type. This would allow us to use the override in daily too.

UI:

When changing a flag twice, the ui shows the modified indicator even when the setting returned to it's default state and requires to apply the changes. But there is no change to the defaults.

Design system additions are a good candidate for a separate PR.

[rafaeltonholo]

Design system additions are a good candidate for a separate PR.

I have moved the implementation of the Horizontal Pager to the PR #10131. Also included the implementation for the HorizontalPagerPrimary

[rafaeltonholo]

Hi @wmontwe, I've changed the implementation to something close to your suggestion. Please take a look and let me know if it is better now.

[wmontwe]

I left some comments.

Non-blocking: this sparks an idea around reactive feature flags. Probably a separate task.

interface FeatureFlagFactory {
    fun createFeatureCatalog(): List<FeatureFlag>
}

// Change to:
interface FeatureCatalogProvider {
    fun getCatalog: Flow<List<FeatureFlag>>
}

then

class InMemoryFeatureFlagProvider(
    featureCatalogProvider: FeatureCatalogProvider,
    featureFlagOverrides: FeatureFlagOverrides,
    mainDispatcher: CoroutineDispatcher = Dispatchers.Main,
    scope: CoroutineScope = CoroutineScope(SupervisorJob() + mainDispatcher),
) : FeatureFlagProvider {

    private val combinedFlags: StateFlow<Map<FeatureFlagKey, FeatureFlag>> =
        combine(
            featureCatalogProvider.getCatalog(),
            featureFlagOverrides.overrides,
        ) { defaultsList, overridesMap ->
            val defaults = defaultsList.associateBy { it.key }
            val overrides = overridesMap.mapValues {
                FeatureFlag(key = it.key, enabled = it.value)
            }
            defaults + overrides
        }.stateIn(
            scope = scope,
            started = SharingStarted.Eagerly,
            initialValue = emptyMap(),
        )

    override fun provide(key: FeatureFlagKey): FeatureFlagResult {
        val enabled: Boolean? = combinedFlags.value[key]?.enabled

        return when (enabled) {
            null -> FeatureFlagResult.Unavailable
            true -> FeatureFlagResult.Enabled
            false -> FeatureFlagResult.Disabled
        }
    }
}

[rafaeltonholo]

@wmontwe, I've addressed all the comments and created a ticket (#10154) to migrate the FeatureFlagProvider to a reactive approach.

[wmontwe]

Thank you!