Investigate adding feature flags to v3

[bmorelli25]

Summary

Serverless documentation provides a unique use case—writers sometimes don't have a good idea of when a feature will go live in the product. We'd like to add a way for writers to add content to the documentation behind a feature flag. Ideally, this feature flag can later be enabled by product or engineering when the feature goes live. This will give us more granular control over when content is published, and allow us to plan ahead better.

Ideas

• Launch Darkly - LD is used by multiple engineering teams and looks easy to implement in a python application. We could explore adding a custom directive that conditionally publishes content by polling LD to determine if a feature flag has been enabled
  • Pros: FFs can be enabled/disabled outside of the docs
  • Cons: Have to integrate a third-party tool.
• Sphinx ifconfig - a much simpler option where we only publish content if the value of a variable is set to true.

Things to think about

• Both of these methods will leave conditional statements in the docs after content is enables. Writers will likely need to periodically go into the docs and clean up unused conditionals.
• How will linking work?
• How will inclusion work?

[lcawl]

This also overlaps with the versioning requirements (#49). For example as we consolidate more versioning schemes into each page and have fewer (if any) branches of content, we will need to rely a lot on the "coming" admonition and/or have a way to show/hide features depending on their availability in each context.

It would also be nice to able to turn feature flags on/off for review purposes (e.g. when previewing content related to unreleased features on the staging site per #53)