implement caching for feature flag

[danoswaltCL]

Times from load tests were okay, but could be better, this could still creep up on us as a performance issue as more flags are added. I propose we cache the this.featureFlagRepository.getFlagsFromContext(context); call.

Requirements:

• Investigate caching for getting all feature flags.
• Clear cache on any change to the flags table, or segments associated with the flags.
• Test with jmeter to compare (in local, and then in staging).

[VivekFitkariwala]

Another small optimisation is not to wait for exposure to get saved.

[danoswaltCL]

@VivekFitkariwala so just remove the await here, yes, fire and forget it? That may worth testing in isolation to see the impact, that may be the safest thing to try actually if we want to squeeze in a hotfix....
@bcb37 thoughts?

try {
      await this.dataSource.transaction(async (transactionalEntityManager) => {
        const exposureRepo = transactionalEntityManager.getRepository(FeatureFlagExposure);
        const exposuresToSave = includedFeatureFlags.map((flag) => ({
          featureFlag: flag,
          experimentUser: experimentUserDoc,
        }));
        if (exposuresToSave.length > 0) {
          await exposureRepo.save(exposuresToSave);
        }
      });
    }

[danoswaltCL]

This is what we looked like during a pretty high load. They are looking at performance issues in the Mathia release and delaying release, I don't want to be blamed, they like to point at UpGrade. If we cache these feature flag SELECTs, we have big $$ savings: