feat: Unify logging behavior across environments

[ikeith]

This branch updates the rules for when/how statements should be logged at runtime to reconcile differences between JS and native implementations. Previously, in the default case of hideLogs in the config file being either false or missing, the native code would log statements in production builds while the JS code would not. The previous boolean flag was insufficient for describing the state(s).

• loggingBehavior is a new config option with possible values of none, debug, and production. Both JS and native code follow the same rules:
  1. If none, no log statements are generated.
  2. If debug (the default), log statements are generated in debug builds but not production builds.
  3. If production, log statements are generated in all builds.
• hideLogs is now deprecated in the config file with a warning in the CLI. If loggingBehavior is absent but hideLogs exists, false is treated as debug and true is treated as none.
• The JS bridge now has a isLoggingEnabled flag to avoid the conflation between debug and logging states.

Companion documentation change: ionic-team/capacitor-site#258

Closes #3723

[thomasvidas]

Is there ever a situation where we'd native native logs but not webview logs? Would that be an option worth exploring?

[jcesarmobile]

Added a few minor comments.

I personally don't like the "production" name. There is already a lot of confusion between the web production build and the native production build. Having a "production" value looks like it's the value you should use for the production build, so can lead to users enabling logs in production builds while thinking they are disabling it.

[ikeith]

I personally don't like the "production" name.

I'm open to ideas. "release", perhaps? I was trying to keep the values short but we could use longer, more descriptive strings like "allowInProduction" or "disabledForRelease" or something. But those could get awkward.

[ikeith]

Is there ever a situation where we'd native native logs but not webview logs? Would that be an option worth exploring?

@thomasvidas I can't think of one. We could offer it but, logically, then we should also offer the inverse, i.e. web logs but not native logs. But that feels like a lot of complication for a relatively simple feature. You'll need to parse a bunch of noise to find the info you need no matter what. I think the biggest concern is leaking sensitive information by logging in release builds without realizing it (which can happen now).

[thomasvidas]

LGTM.

bridge.ts moved over to native-bridge.js in my PR, but I think everything else should merge in cleanly

[jcesarmobile]

two minor things