When DEBUG, include posthog.js with local posthog host

[macobo]

Changes

This was initially included in session recording project, but removed in
#1837

Wins of doing it this way:

• Less noisy data in production.
  • Slack thread by @paolodamico: https://posthog.slack.com/archives/C018RGRS10S/p1602486169005700
• Can develop/dogfood feature flags for development.
  • Used in session recording - can "merge" half-complete solutions that
    are not yet ready for release
• Can possibly mock feature flags in cypress tests
• Session recording can be done in localhost now :)

Downsides:

• If feature flags are not cleaned up, this may cause drift between
  local checkouts and production.

Checklist

• All querysets/queries filter by Team (if this PR affects any querysets/queries)
• Backend tests (if this PR affects the backend)
• Cypress E2E tests (if this PR affects the front and/or backend)

[paolodamico]

In general terms my only concern with this is that this will cause users running debug instances to get events from their PostHog app usage as events from their own app, which can be a bit disconcerting.

As I'm working on #1755 I ran into the same issue that prompted you to consider this change, my solution (unpushed) was this (though I wasn't considering the Cypress case you mentioned). Basically we this we get feature flags without getting noisy data from debug instances.

<script>
    !function(t,e){var o,n,p,r;e.__SV||(window.posthog=e,e._i=[],e.init=function(i,s,a){function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}(p=t.createElement("script")).type="text/javascript",p.async=!0,p.src=s.api_host+"/static/array.js",(r=t.getElementsByTagName("script")[0]).parentNode.insertBefore(p,r);var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",u.people=u.people||[],u.toString=function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e},u.people.toString=function(){return u.toString(1)+".people (stub)"},o="capture identify alias people.set people.set_once set_config register register_once unregister opt_out_capturing has_opted_out_capturing opt_in_capturing reset isFeatureEnabled onFeatureFlags".split(" "),n=0;n<o.length;n++)g(u,o[n]);e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
    posthog.init('sTMFPsFhdP1Ssg', {api_host: 'https://app.posthog.com'{% if debug %}, autocapture: false, capture_pageview: false{% endif %}})
</script>

[macobo]

Thanks for the feedback @paolodamico

In general terms my only concern with this is that this will cause users running debug instances to get events from their PostHog app usage as events from their own app, which can be a bit disconcerting.

@paolodamico Isn't that desirable? My assumption is DEBUG = development environment, correct me if I'm wrong. If not, maybe worth adding another env variable?

Basically we this we get feature flags without getting noisy data from debug instances.

This has significant downsides - having to manage dev feature flags from prod makes dogfooding them harder. See wins 2-4

[Twixes]

I like this a lot, I think we can assume that DEBUG users are likely to actually want these events for testing PostHog on actual data (I want em!). And for those who don't want them, there's env var OPT_OUT_CAPTURE.

[yakkomajuri]

+1 for this.

[paolodamico]

Well my only outstanding concern is with users that run the app with DEBUG=1 because they want to test something / use quickly, but I do agree that DEBUG should be intended for development and therefore this should be the best approach right now.

[paolodamico]

I think this PR may have introduced a minor typo that breaks feature flags and all tracking. See below screenshot of the current code on PostHog cloud, notice the ' in the api_host.

[Twixes]

https://docs.djangoproject.com/en/3.1/ref/templates/builtins/#safe should be of use here.

[macobo]

#1868