[UPDATED] Simpler logging refactor

[uberbrady]

This is another version of #16779 - a little bit of a simpler approach. I think I like it.

Updated

This is now getting pretty close. The previously-made updates to tests have definitely helped to catch bugs in this implementation, which I'm pretty happy with.

Right now, we should see that there are still a few failing tests. These all boil down to different choices of implementation. Before this PR we weren't quite too rigid about logging things separately when they were created versus checked out. And we weren't too rigid about making sure that the API worked exactly the same as the GUI in these cases. But, should we be?

My opinion - creating an asset and immediately checking it out via GUI or API should both do the same thing - log a 'created' action_log and then immediately a 'checkout' action_log. I think the extra action_log entries make it clearer and easier to 'replay' the history of an object.

To-Do

• I recently introduced - or, rather, sorta re-introduced, the Loggable method saveWithLogAction() (which I think is a dumb name, I should fix it). I should probably apply that across the code base for consistency.
• This probably needs some extensive testing. It touches a lot of the 'heart' of Snipe-IT - the action_log. While it does try to ensure that some type of action_log happens any time the object-in-question gets modified, or if the various logging methods are called, it's possible that something could have been missed, or there are still subtle bugs around.
• We could probably stand to do another squash - as there are a ton of commits. Unfortunately, the vrious 'squash' attempts I've made in the past seem to obscure the fact that the Loggable trait got moved into the Traits sub-directory, which has made later merges much, much harder.
• Because of how git works, some changes that have happened to some of the files that have been deleted keep making those files pop back up when we try and re-merge develop into this branch. It's not always easy to see what the changes were to merge them back into wherever they belong. I've done my fair share of archeology to try and figure that out, but I could've easily missed something.

Next Steps

1. I have two PR's waiting on this one, which will need to be re-pointed and updated to match this new 'style' of handling the action_logs:

• • Move the user-merge behavior into the user and use it where we merge uberbrady/snipe-it#7
• • Get rid of LogListener's LogListener lines uberbrady/snipe-it#8

2. I think once all that is done and everything is merged, it will be the case that the events that we're firing are really only notification-triggers. If that's true, we might be able to fully "de-event" the notifications, and trigger them all directly with ->notify(). if that makes sense. I feel like the Slack/webhook notifications and the email notifications are sufficiently different that I would like to see if it's possible to split them off - but that might only work with the event'ed notifications, and not with the ->notify() based ones.
3. I think this sets us up to do the 'quantitizable' changes that we've been pondering - having one grand-unified method of making all action_log entries makes it much easier to start to treat "quantities" as first-class fields and not simple repetitions.
4. I think this also sets up some of the "Order" and "Purchase Order" additions that we've been considering simpler as well.
5. This puts us in a good position to unify check-in, and checkout, perhaps as an Interface, or maybe as @spencerrlongg 's "Action" idea. But reducing duplicated code here is good.

[marcusmoore]

I also like this approach more than #16779. There are still a lot of todos and fixmes so I'm going to hold off on a full review besides just a few comments for anything I see on a quick skim.

[snipe]

Looks like you've got some tests failing in 8.2

[uberbrady]

This is cleaned up heavily in #17463 - I'm closing this one.