The `deprecation` function and Puppet 8 are not compatible

Describe the Bug

I wanted to discuss the issue of puppet's strict mode and the deprecation function in the puppetlabs-stdlib module. This was discussed previously in:

https://github.com/puppetlabs/puppetlabs-stdlib/issues/1365
https://github.com/puppetlabs/puppetlabs-stdlib/issues/1373
https://tickets.puppetlabs.com/browse/PUP-11868

As described in those issues, the problem is that all deprecations become hard errors when "strict=error", which is the default in puppet8. In practice, this means you can't really use "strict=error" and need to relax the setting to "strict=warning".

Expected Behavior

I would expect the deprecation function to behave similarly to puppet when its Puppet.deprecation_warning method is called. That is, the strict setting should not control whether the deprecation warning is displayed or not. Instead, it should be controlled by the disable_warnings=deprecations setting, similar to how -Wno-deprecated-declarations can silence warnings in GCC.

From my perspective, the problem is that both puppet and stdlib are trying to decide how to handle deprecation warnings and the two approaches are not compatible. To understand the disconnect, suppose you call Puppet.deprecation_warning('message', 'key'). The warning is always displayed when strict is set to error, warning and off, respectively:

$ bundle exec ruby -rpuppet -e " \
  Puppet.initialize_settings; \
  Puppet::Util::Log.newdestination(:console); \
  Puppet[:strict] = 'error'; \
  Puppet.deprecation_warning('message', 'key')"
Warning: message
   (location: -e:1:in `<main>')

$ bundle exec ruby -rpuppet -e " \
  Puppet.initialize_settings; \
  Puppet::Util::Log.newdestination(:console); \
  Puppet[:strict] = 'warning'; \
  Puppet.deprecation_warning('message', 'key')"
Warning: message
   (location: -e:1:in `<main>')

$ bundle exec ruby -rpuppet -e " \
  Puppet.initialize_settings; \
  Puppet::Util::Log.newdestination(:console); \
  Puppet[:strict] = 'off'; \
  Puppet.deprecation_warning('message', 'key')"
Warning: message
   (location: -e:1:in `<main>')

In order to silence the deprecation, you can set disable_warnings=deprecations and this works even when strict=error:

$ bundle exec ruby -rpuppet -e " \
  Puppet.initialize_settings; \
  Puppet::Util::Log.newdestination(:console); \
  Puppet[:strict] = 'error'; \
  Puppet[:disable_warnings] = 'deprecations'; \
  Puppet.deprecation_warning('message', 'key')"
$ 

Steps to Reproduce:

I would expect the following to print a deprecation warning instead of failing compilation:

$ bundle exec puppet apply --strict=error puppet apply -e "deprecation('key', 'message')" 
Error: Evaluation Error: Error while evaluating a Function Call, deprecation. key. message at ["unknown", 1]:["unknown", 0] (line: 1, column: 1) on node localhost

I would expect the deprecation warning to be silenced and for compilation to succeed:

$ bundle exec puppet apply --strict=error --disable_warnings=deprecations puppet apply -e "deprecation('key', 'message')"
Error: Evaluation Error: Error while evaluating a Function Call, deprecation. key. message at ["unknown", 1]:["unknown", 0] (line: 1, column: 1) on node localhost

Proposal

1. If the deprecation function is called with use_strict_setting=true and strict != :off, then only raise if disable_warnings doesn't include deprecations.

OR

2. A bigger change would be to remove this line:

    raise("deprecation. #{key}. #{message}") if use_strict_setting && Puppet.settings[:strict] == :error

and always just call Puppet.deprecation_warning. It's possible that folks could be relying on the raise behavior? Though I think it's doubtful because strict=error wasn't actually usable prior to puppet8, see https://github.com/puppetlabs/puppet/wiki/Puppet-8-Compatibility#strict-mode

Start by reproducing the two puppet apply commands and inspect the deprecation function's handling of use_strict_setting, Puppet.settings[:strict], and disable_warnings. Done means deprecations warn under strict=error and can be silenced with disable_warnings=deprecations, with tests covering both behaviors.