Audit entries rework

[lauraneto]

Description

• Moved logic related to the IAuditEntryRepository (umbracoAudit) from the AuditService to the new service
• Introduced new async methods
  • Using ids (marked as obsolete - for easier transition from the previous Write method)
  • Using keys
• Added migration to add columns for performingUserKey and affectedUserKey and convert existing user ids
• Moved and updated integration tests related to the audit entries to a new test class AuditEntryServiceTests
• Added unit tests class AuditEntryServiceTests and added a few unit tests
• Adjusted usages of the old AuditService.Write method to use the new one (mostly notification handlers)
• Added Task<Attempt<Guid>> TryGetAsync(int id) and Task<Attempt<int>> TryGetAsync(Guid key) methods to IUserIdKeyResolver

Affected notification handlers that trigger audit logs

• BackOfficeUserManagerAuditer
  • UserLoginSuccessNotification
  • UserLogoutSuccessNotification
  • UserLoginFailedNotification
  • UserForgotPasswordRequestedNotification
  • UserForgotPasswordChangedNotification
  • UserPasswordChangedNotification
  • UserPasswordResetNotification
• AuditNotificationsHandler
  • MemberSavedNotification
  • MemberDeletedNotification
  • AssignedMemberRolesNotification
  • RemovedMemberRolesNotification
  • ExportedMemberNotification
  • UserSavedNotification
  • UserDeletedNotification
  • UserGroupWithUsersSavedNotification
  • AssignedUserGroupPermissionsNotification

Testing

Run the project in the main branch and do a few user operations. Then, switch to this branch, perform the update and do additional user operations.
Check the database to ensure that:

• The new columns for the user keys were added
• The migration filled in the keys based on the ids (if the user still exists)
• New entries were added correctly and contain both the id and key of the users

❓ Pending questions ❓

1. What to do regarding user id 0 (SYSTEM, Unknown)?

• Is it ok to give it key 00000000-0000-0000-0000-000000000000 or do we want it to be null? (both in the database and code)
  • If empty guid is preferred, the migration should probably also convert user id 0 to guid empty, to differentiate between ids that weren't found and unknown user.
  • If null is preferred, some changes might be needed in the AddAsync methods (at the moment if the id is 0 or the overload accepting id is used and it cannot convert/find that id, it is saving as empty guid)

[Zeegaan]

Few pedantic comments 😁

[lauraneto]

@Zeegaan I updated the code based on your feedback and also did some additional changes:

• Handle the upgrade state better - in the audit entry repository, I am now catching the db exception while in upgrade state and performing a more "manual" insert with only the fields that existed previously. I couldn't find an example of this being done in the rest of the codebase, only the error being ignored completely, so please point me in the right direction if there is another place where this is being done more gracefully!
• Remove the UnknownUserKey that was added and adjust the logic to use/store null instead of that id - after some discussions it was clear that the unknown user is probably a "legacy" thing that we want to avoid using.

[Zeegaan]

Looks good, tests good 🚀