Add feature to hide sensitive data in logs

[ahangarha]

With this implementation, we can set the sensitive data pattern in the closest place to the sensitive data. This can (hopefully) prevent accidental typos in pattern matching.

I couldn't implement test for this feature.

---

Closes #97

[ahangarha]

Having it in a single place (probably in the Shell class, since it implements debug) would make it easier to update later on, and easier to find all patterns.

I initially thought about this but dropped it because

• That means we pass many other strings through that hiding process for no reason. We have a small number of debugging logs for now. But let's say we add more items to be shown in verbose mode. That time, we should process so many texts where we know there is no sensitive data.
• Shell class shouldn't know about sensitive data passed to its methods.
• Separating the patterns from where they get generated increases the chance of leaving out some old and unused patterns. Keeping the pattern close to where it is related to, helps us to make minimal regex for that case only.

Still, if we are sure that we are not going to have any other pattern in the future, we can simplify the logic. In that case, using class constant is a good solution.

[rafaelgomesxyz]

I initially thought about this but dropped it because

• That means we pass many other strings through that hiding process for no reason. We have a small number of debugging logs for now. But let's say we add more items to be shown in verbose mode. That time, we should process so many texts where we know there is no sensitive data.
• Shell class shouldn't know about sensitive data passed to its methods.
• Separating the patterns from where they get generated increases the chance of leaving out some old and unused patterns. Keeping the pattern close to where it is related to, helps us to make minimal regex for that case only.

Still, if we are sure that we are not going to have any other pattern in the future, we can simplify the logic. In that case, using class constant is a good solution.

My main concern is repetition, since the current implementation means that we'll have a hide_sensitive_data method in each class that logs sensitive data.

Why don't we move hide_sensitive_data to a helper and have it accept the pattern as a param? Then we can use it like:

hide_sensitive_data(message, pattern)

We could then add a sensitive_data_pattern param to the perform and perform! methods, that defaults to nil, and use the params for passing the pattern around, instead of an instance variable.

[ahangarha]

We could then add a sensitive_data_pattern param to the perform and perform! methods

I thought about this too. The issue with this is that it is strange to call a method for performing some action but also it accept parameters unrelated to what it is supposed to do. (though it already does more than one thing).

I thought it is better to not change the parameters and limit the changes in the implementation only.

Why don't we move hide_sensitive_data to a helper and have it accept the pattern as a param?

I think this is good. I do it 👍🏾

[rafaelgomesxyz]

Approved with one small thing, no need for re-review.