Fix TypeError and refactor processors

[rimas-kudelis]

One of the current processors caused one of our CI steps to fail like this during the build:

  [TypeError]                                                                  
  Egeniq\Monolog\Gdpr\Processor\RedactEmailProcessor::__invoke(): Return value must be of type array, null returned                                       

I didn't really try reproducing that locally (too much hassle), but my first instinct is to blame current code of the Processor in question, which first converts the whole array into a JSON string, then performs a preg_replace_callback on that string, and then attempts to convert the string back to an array, and doesn't even check the result. Thus I decided to refactor these processors to employ a cycle and a recursion instead. While doing this, I also noticed that the code of both of the processors is basically the same, with the exception of the regex that is used. So I figured why not move everything into the abstract class and just have a single constant in both final processors. WDYT?

BTW, I also have a separate branch where I'm working on Monolog 3 support, but Seldaek/monolog#1680 is currently blocking me. :)

[rimas-kudelis]

BTW I don't know where you took the regex from or if you made it yourself, but I think it might make sense to use the one from the HTML5 spec (sans the start and end of string markers) instead:

/[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*/

The tests pass with both, but this one is shorter. :D

[rimas-kudelis]

Hmmm, I just noticed this sentence in the README:

WARNING: These processors will json serialise your `$context`. This may cause some undesired side-effects.

I wonder if I should a) adjust it to say that only strings within arrays will be touched or b) reintroduce JSON serialization, but deserialize the data back to array right away, in order for all objects to be converted to arrays, so that I need less code to traverse everything.

EDIT: I think I prefer option a). I've already hit issues with the serialization/deserialization approach, becaue the formatter we're employing expects $record['datetime'] to be an instance of DateTimeInterface