More clean-up with Actor redesign:

• Per dc443y, use a more generic event class in models/ControlLoopEventContext and drools-apps/eventmanager
  • enrichment data isn't always available either
  • refactor ControlLoopEvent to only include closedLoopControlName and requestID, which are the only fields that all events have in common
• Custom Query should probably be moved from Actor startPreprocessor back to the invoking code
  • How to specify data to be extracted from the custom query to be used when constructing requests (e.g., service-instance-id).  What if the use case wants to use a different mechanism for gathering the relevant data (i.e., instead of custom query)?
• startPreprocesssorAsync() should run guard, by default; only A&AI and Guard actors don't need it
  • Or should guard requests be moved out of the Actor and done by the use case (i.e., rules)?  Seems to make sense to be done within the actor, as the actor knows what parameters to pass to the guard (e.g., vf-count)
• Simpler code to request A&AI custom query, since it's needed so often
• Make LOCKs an Actor
• Rename XxxActorServiceProvider to XxxActor?
• Possibly move Util.translateXxx() methods to policy-common
• Rearrange the modules per Liam's review comment
• REST Actors should populate standard ONAP headers (this was missing from the legacy actors, too)
• Ability to toggle guards on and off dynamically
• Decide where to put Actor Service singleton (i.e., within drools-apps)
• Modify Serialization classes to use StandardCoder
  • May also move them to drools-apps, which is the only repo that uses them
• Change "path" to "uri" in the various XxxParams classes and in the corresponding property files
  • Other team members agree with this proposal

Won't do:

• Add "guard" project with GuardConstants so other projects don't have to refer to classes in actor.guard
  • won't do: this will no longer be needed once the actors stop performing pre-processor steps
• Eliminate OperatorConfig so subclasses can just use XxxParams, if those are sufficient?
  • won't do: config provides the blocking executor, which all operations need at some point
• Shorten BidirectionalTopicXxx to BiTopicXxx?
  • won't do: consensus was that the current name is more descriptive