Add SSM-based feature flags

[lorenyu]

Ticket

Resolves #{TICKET NUMBER OR URL}

Changes

• Add modules/feature_flags
• Add feature_flags_config in app-config/env-config/feature_flags.tf with ability to override per environment via feature_flags_override
• Create feature flags as SSM parameters in infra/<app_name>/service/feature_flags.tf
• Add feature flags as environment variables with FF_ prefix

Context for reviewers

Re-adding feature flag support using SSM params and environment variables

Testing

see navapbc/platform-test#178

[doshitan]

Not blocking, but given this is tied to SSM/returns ARNs, I wonder if we should name the module like ssm_feature_flags or feature_flags__ssm (assuming we eventually develop a "feature_flag" interface of which this is one implementation) or something?

[doshitan]

Suggested change

	import logging
	import os
	import boto3
	logger = logging.getLogger()
	def is_feature_enabled(feature_name: str) -> bool:
	value = os.environ.get(f"FF_{feature_name}")
	return value == "true" if value else False
	import os
	def is_feature_enabled(feature_name: str) -> bool:
	value = os.environ.get(f"FF_{feature_name}")
	return value == "true" if value else False

[doshitan]

Should this be empty (or commented out) in the template?

Doesn't really hurt anything, but potentially confusing/worth a callout in docs that you'll see a FF_FOO/FF_BAR env var in your runtime environment unless you delete these.

Similar for the override in infra/{{app_name}}/app-config/dev.tf

[doshitan]

It might be nice to have the FF stuff partitioned out, something like:

Suggested change

	name = "/service/${var.service_name}/${each.key}"
	name = "/service/${var.service_name}/feature-flag/${each.key}"

If folks name their flags enable_ (or similar) then /service/my-service-dev/enable-new-flow isn't too bad, but /service/my-service-dev/bar would be more confusing than service/my-service-dev/feature-flag/bar.