Habitat: Replace blacklist/whitelist with preferred terminology

[baumanj]

These terms carry unnecessary prejudicial baggage. See https://english.stackexchange.com/questions/51088/alternative-term-to-blacklist-and-whitelist and https://github.com/graphite-project/graphite-web/issues/1569 for more.

As of now there are a number of places in the habitat repo that use this terminology:

CHANGELOG.md
2218:- Add whitelist origin capability to builder builds [\#2455](https://github.com/habitat-sh/habitat/issues/2455)

components/butterfly/tests/integration.rs
54:    net.blacklist(0, 1);

components/butterfly-test/src/lib.rs
164:    pub fn blacklist(&self, from_entry: usize, to_entry: usize) {
171:        trace_it!(TEST: &self.members[from_entry], format!("Blacklisted {} {}", self.members[to_entry].name(), self.members[to_entry].member_id()));
172:        from.add_to_blacklist(String::from(
177:    pub fn unblacklist(&self, from_entry: usize, to_entry: usize) {
184:        trace_it!(TEST: &self.members[from_entry], format!("Un-Blacklisted {} {}", self.members[to_entry].name(), self.members[to_entry].member_id()));
185:        from.remove_from_blacklist(to.member_id());
368:                self.blacklist(*l, *r);
369:                self.blacklist(*r, *l);
380:                self.unblacklist(*l, *r);
381:                self.unblacklist(*r, *l);

components/butterfly/src/server/inbound.rs
66:                            // NOTE: In the future, we might want to blacklist people who send us
76:                            // NOTE: In the future, we might want to blacklist people who send us
86:                                .check_blacklist(msg.get_ping().get_from().get_id())
89:                                    "Not processing message from {} - it is blacklisted",
98:                                .check_blacklist(msg.get_ack().get_from().get_id())
102:                                    "Not processing message from {} - it is blacklisted",
111:                                .check_blacklist(msg.get_pingreq().get_from().get_id())
114:                                    "Not processing message from {} - it is blacklisted",

components/butterfly/src/server/pull.rs
73:                    // NOTE: In the future, we might want to blacklist people who send us
86:            if self.server.check_blacklist(proto.get_from_id()) {
88:                    "Not processing message from {} - it is blacklisted",

components/butterfly/src/server/push.rs
83:                    if self.server.check_blacklist(member.get_id()) {
85:                            "Not sending rumors to {} - it is blacklisted",

components/butterfly/src/server/mod.rs
93:    blacklist: Arc<RwLock<HashSet<String>>>,
121:            blacklist: self.blacklist.clone(),
175:                    blacklist: Arc::new(RwLock::new(HashSet::new())),
357:    /// Blacklist a given address, causing no traffic to be seen.
358:    pub fn add_to_blacklist(&self, member_id: String) {
359:        let mut blacklist = self.blacklist
361:            .expect("Write lock for blacklist is poisoned");
362:        blacklist.insert(member_id);
365:    /// Remove a given address from the blacklist.
366:    pub fn remove_from_blacklist(&self, member_id: &str) {
367:        let mut blacklist = self.blacklist
369:            .expect("Write lock for blacklist is poisoned");
370:        blacklist.remove(member_id);
373:    /// Check that a given address is on the blacklist.
374:    fn check_blacklist(&self, member_id: &str) -> bool {
375:        let blacklist = self.blacklist
377:            .expect("Write lock for blacklist is poisoned");
378:        blacklist.contains(member_id)

components/sup/src/manager/service/config.rs
229:    /// Returns a subset of the overall configuration whitelisted by the given package's exports.

[elliott-davis]

I don't see anywhere in the articles you linked where the reference racial bias. Also, I can't find any reference to racial connotations for blacklisting in wikipedia. I'd like to propose we close this as a non-issue.

[nellshamrell]

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, it costs us very little.

[jonlives]

I concur utterly with Nell here - 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.