Added support for plugins within LogBatchPurger + added archiving in BigObject plugin

[jongpie]

As a follow-up to #287 (and part of a larger overhaul of the plugin framework for the upcoming release v4.7.1), I've reworked even more of the plugin framework to add support for plugins within the LogBatchPurger class

Plugin Framework Changes

• Eliminated the old plugin approach by deleting the abstract class LoggerSObjectHandlerPlugin. It has been replaced with 2 new interfaces:
  1. LoggerPlugin.Batchable - used to create plugins for LogBatchPurger (batch deletion job)
  2. LoggerPlugin.Triggerable - used to create plugins for LoggerSObjectHandler (trigger framework used by Logger)
• Cleaned up the fields on LoggerPlugin__mdt + added new fields to control the sort order of plugins used by LogBatchPurger
• Added a new settings field LoggerSettings__c.DefaultLogPurgeAction__c - this then sets the default value of the field Log__c.LogPurgeAction__c. This field value isn't used by LogBatchPurger directly, but it provides a place for plugins to set/read additional actions that can be used within plugin logic (see BigObject changes below for an example)
  • I've also updated LoggerSettingsController to query for LoggerParameter__mdt records that start with 'CustomLogPurgeAction' so that plugins can define & package new actions. Any matching values will be displayed in the LWC loggerSettings as a picklist option for LoggerSettings__c.DefaultLogPurgeAction__c
• LogBatchPurger now uses a new inner class BatchPurgerInput to provide contextual info to plugins
  • I realized earlier today that the class LogBatchPurger.BatchPurgerInput and LoggerSObjectHandler.SObjectHandlerInput will both need to be changed to top-level classes so that Flow plugins can use them. From this page, Apex-defined types can't be used in Flow unless they are top-level classes. I've already scope-creeped in this branch a lot, so I'll make this change after merging this PR into the plugin-framework-overhaul branch.
• Scope creep: standardized some of the @TestVisible methods used throughout the codebase to mock custom metadata records

BigObject Plugin Changes

The BigObject plugin has been updated to also work as a batch purger plugin (in addition to being an SObject handler plugin that @jamessimone implemented in #287)

• Split the class LogEntryArchiveBuilder into 2 classes:
  1. LogEntryArchiveBuilder - this now only handles converting a LogEntryEvent__e into a LogEntryArchive__b record (implemented via Big Object Plugin #287), as well as converting a LogEntry__c record into a LogEntryArchive__b record (to cover most of the functionality in Add support for archiving Log__c and LogEntry__c records into a BigObject #128)
  2. LogEntryArchivePlugin - this new class implements the interfaces LoggerPlugin.Batchable and LoggerPlugin.Triggerable so archiving can be used as the initial storage place (when a user's save method == BIG_OBJECT) as well as a secondary storage place (when a Log__c has LogPurgeAction__c == 'Archive')
• Added more fields on LogEntryArchive__b to (more or less) match the list of fields on LogEntryEvent__e
• The BigObject plugin now includes a custom value 'Archive' for the field LoggerSettings__c.DefaultLogPurgeAction__c. When LogBatchPurger executes, any matching Log__c/LogEntry__c/LogEntryTag__c data will be archived into LogEntryArchive__b before being deleted by LogBatchPurger
• I've also made a few tweaks to the index for LogEntryArchive__b, but I'm guessing we'll probably try a few other variations on what to use within the index
• I also included some placeholder metadata that will eventually be used to display LogEntryArchive__b records via a new LWC + custom tab

Slack Plugin Changes & Log Retention Rules Plugin Changes

• The metadata for both plugins have been updated to use the latest changes to the plugin framework - there shouldn't be any functional changes

[jongpie]

@jamessimone there are a few failing tests in this PR that I'm not too worried about for this PR - 1 is an issue for Flows that I'll fix in the plugin-framework-overhaul branch, and a few test failures are because I've only created the skeleton for a new LWC/tab to show LogEntryArchive__b (and I included some System.assert(false) calls as placeholders/reminders)

[jamessimone]

Awesome. Incredible write-up — looking forward to reviewing!

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (feature/plugin-framework-overhaul@b3ebafc). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head 872b052 differs from pull request most recent head f19e999. Consider uploading reports for the commit f19e999 to get more accurate results

@@                         Coverage Diff                          @@
##             feature/plugin-framework-overhaul     #288   +/-   ##
====================================================================
  Coverage                                     ?   93.67%           
====================================================================
  Files                                        ?       40           
  Lines                                        ?     4176           
  Branches                                     ?       86           
====================================================================
  Hits                                         ?     3912           
  Misses                                       ?      259           
  Partials                                     ?        5           

Flag	Coverage Δ
Apex	94.52% <0.00%> (?)
LWC	88.60% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b3ebafc...f19e999. Read the comment docs.