Consistent Fernet Key Handling Strategy

**Rationale:** https://lists.apache.org/thread/xsc1174o6yjogxsvrq60nn93l0r4g91g We need to harden our security with a consistent and well-documented approach to Fernet Keys. - Treating explicitly empty values as intentional use of NullFernet (with a strong warning) - Improving differentiation between “not specified” and “explicitly empty” - Generating and persisting a Fernet Key when not specified - Ensuring a consistent approach across our default values - Failing on invalid non-empty keys Case | Meaning | Expected Behaviour | Important Points -- | -- | -- | -- Explicitly empty ("") | User deliberately disables encryption | Use NullFernet + show a huge warning | “not specified” and “explicitly empty” Not specified | No key from env, config, or defaults | Generate & persist a new key; fail if not possible | It may fail due to permissions, etc. Specified & non-empty | User provides a Fernet key | Validate; fail if invalid format | ## What The Fernet Key implementation should reliably differentiate between: - Not specified - Explicitly empty ("") - Specified & non-empty Improving differentiation between “not specified” and “explicitly empty”. **Suggestions:** We can either assume `""` as empty and absence in `Not specified` or create a specific value for `Explicitly empty` case and default to `Not specified` and generate a new one. * Use `""` and empty state from config, env vars, etc... * Create a specific key for `Explicitly empty` state, such as `NOT_ENCRYPTED` or `EMPTY_FERNET`. In both cases, we should double-check defaults in `.cfg`, `prod image env vars`, etc... ## Scope * Identify if the Fernet is `Explicitly empty` or `Not specified` cases? * Generate a new Fernet Key and persist if `Not specified` * Give **huge** warning if it is `Explicitly empty` * Double check `Specified & non-empty` case for exceptions * Document the new generation behaviour in the documents ### Committer - [x] I acknowledge that I am a maintainer/committer of the Apache Airflo…