Replace "blacklist" and "whitelist" with less problematic terminology

[baumanj]

Resolves #5287

Signed-off-by: Jon Bauman 5906042+baumanj@users.noreply.github.com

[thesentinels]

Thanks for the pull request! Here is what will happen next:

1. Your PR will be reviewed by the maintainers
2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

[christophermaier]

I've also not been able to find any racial overtones in either etymology or usage of "blacklist", so I don't see this as being in the same class of change as, for example, the (completely justified) jettisoning of "master / slave" terminology in favor of "leader / follower".

That being said, if a change is desired, I'd rather it be one that maintains the same semantics as the term being replaced. I feel like "block" / "unblock" would do this better than "deny" / "allow", in particular because "unblock" carries with it the implication that the thing being unblocked was previously blocked, whereas "allow" is more vague on that point.

That maintains the same meaning as "blacklist", without using the term "blacklist", and the functions and variables now describe what they do in literal, rather than metaphorical, terms.

[jonlives]

(re-paste of most of my comment from #5287 ) This is a change that costs us very little to implement. I'd rather see us take the time to change language that could be potentially problematic rather than exhaustively proving whether or not it is. The work is already done here, and this treating this as a non-issue is not a path I want to see us take.

[nellshamrell]

(also a re-paste of most of my comment from #5287)

We don't lose anything by changing the terminology - if it would potentially make someone's journey through this world (and our code base) a little less painful than by all means let's change them (this isn't something we should require exhaustive proof of) and it costs us so little.