in the /history response since we have the `passthrough_module` key
for that purpose.
While that might be handy in some situations,
mixing actions and module names is confusing in general.
[Rework] Breaking: Do not report soft reject in history
We can have much more clear information if we store the real action in
case of `soft-reject`. In this case, we can just imply that a module
that has set this action is an action itself, such as:
* greylist
* ratelimit
* multimap
* antivirus rule name
This policy seems quite reasonable, as `soft reject` has no meaning on
its own.