fix(security): restore default value of SESSION_COOKIE_SECURE to False

[sfirke]

SUMMARY

The default value of SESSION_COOKIE_SECURE was historically False. This was changed unintentionally when we enabled TALISMAN_CONFIG by default. That comes with unstated, implicit settings including making SESSION_COOKIE_SECURE = True. This contradicts our documentation (issue #25854).

More importantly, it contributed to a critical problem where new users who have not enabled HTTPS yet as part of their setup encounter a login loop and are unable to use Superset. The canonical issue here is #24579 (comment), please review that thread ending with the comment I linked.

When users discuss this problem in the issues, the two most upvoted "fixes" are to disable Talisman entirely or to revert to Superset 2.1.0 (which did not have Talisman enabled by default) 😬

I'm not an expert in this area and there might be more we need to to do to get a combination of security values that works for out-of-the-box setups. But this PR seemed like a good simple start in that it's reverting an unintended change that came when we implemented Talisman CSP.

TESTING INSTRUCTIONS

Install a new instance of Superset with this config value in Talisman? Two users in that thread report that this config change enabled them to install and use Superset.

ADDITIONAL INFORMATION

• Has associated issue:
  • Fixes Documentation incorrect: SESSION_COOKIE_SECURE is true by default #25854, fixes Login page loops indefinitely #24579 at least enough that it can be closed and, if a problem persists, a new issue created
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API