feat(launch darkly perform intake): add launch darkly logic to label mappers

[jdinh8124]

Purpose

Add show hide logic of perform intake logic with launch darkly flags

[mdial89f]

Would it be possible to move where this logic occurs?
https://github.com/Enterprise-CMCS/macpro-mako/blob/juliet/src/packages/shared-utils/package-actions/rules.ts#L99
^^ This is the rule that governs if the action is available or not. So maybe something like
check: (checker, user) => isCmsWriteUser(user) && checker.needsIntake && <boolean that indicates its enabled by a feature flag, or at least not disabled>
I think that's a better place to add the condition

Further, a question: you think it'd be possible and/or wise to resolve all feature flags in a single file? something so we don't need to useLDClient everywhere we want to check for a feature flag. Not sure.

[jdinh8124]

Would it be possible to move where this logic occurs? https://github.com/Enterprise-CMCS/macpro-mako/blob/juliet/src/packages/shared-utils/package-actions/rules.ts#L99 ^^ This is the rule that governs if the action is available or not. So maybe something like check: (checker, user) => isCmsWriteUser(user) && checker.needsIntake && <boolean that indicates its enabled by a feature flag, or at least not disabled> I think that's a better place to add the condition

Further, a question: you think it'd be possible and/or wise to resolve all feature flags in a single file? something so we don't need to useLDClient everywhere we want to check for a feature flag. Not sure.

@mdial89f Is there a way to pull aws keys in the shared utils package? I know the way we've been doing it has been through serverless in the other services, should we be going about it in a different way here?

As for your second question, this is the way manage care review is doing it, but I can do some more research on alternative paths to clean it up