Replace Whitelist with Safelist

[mrunalk]

This is a BREAKING CHANGE. Consumers currently relying upon scrub_whitelist or setWhitelist will need to update their code or configuration to scrub_safelist and setSafelist respectively.

[waltjones]

I know the assignment here says $options is private, but according to the docs the user has access to set this. Will this change affect existing users?

[mrunalk]

@waltjones, you bring up a good point. I am not totally sure how options are exposed. Let me look into it.

[bishopb]

Two points:

1. We can add a new key, but we shouldn't remove scrub_whitelist at the same time: there should be at least a minor version increment between them.

2. I prefer allowlist instead of safelist, because the opposite is (IMO) clearer: denylist vs unsafelist. Is the "safelist" nomenclature a standard in Rollbar?

[waltjones]

allowlist was considered, but the consensus was to standardize on safelist (and blocklist.)

The CH story for each of the SDKs is to only deprecate, not remove, public facing names until the next major version release.

[icsahn-rollbar]

Looks good except what @waltjones pointed.
We are exposing scrub_whitelist and it will break backward compatibility, which should be fine if document it properly and give notice for depreciation.
Ref: https://docs.rollbar.com/docs/php-configuration-reference

[bishopb]

I have marked this as "Status: 2 - Accepted" because the concept and need is understood; there are still some questions on the implementation, though: see above.

[bishopb]

This change is not relevant to the implementation. Needs reversion.

[akornich]

lgtm