Policy classes and interfaces structure

[ndr-brt]

As mentioned in #1832:

• all the policy thing is pretty confusing, I will create a discussion about how to improve its structure, now we have:
  • policy-spi that only contains two interfaces, one used only by the transfer process, and the other is the repository for PolicyDefinition
  • core-spi/policy package, that contains interfaces for the policy-engine
  • policy-evaluator that contains all the policy related model classes (no logic)
  • policy-engine that contains the PolicyEvaluator class and accessors
  • base-core/policy package, that contains the policy-engine implementation

I think the structure can be improved. Don't have a proposal right now but I will try to put down one in the next days.
@jimmarino I know that you have an opinion on how the policy thing should be structured, your hints will be appreciated

[ndr-brt]

The proposal for moving forward with this is:

• rename policy-evaluator to policy-model and move the module in the spi/common folder
• rename policy-engine to policy-evaluator and leave it in the core/common folder
• let the policy-spi as it is
• move the classes/interfaces from core-spi/policy package to either policy-model or to a new policy-evaluator-spi module. @jimmarino wdyt?
• move the classes/interfaces from base-core/policy package to policy-evaluator

EDIT: PolicyDefinition class is currently located in core-spi and it can be moved to policy-spi
EDIT2: we have two AtomicConstraintFunction interfaces, with a slightly different signature

[jimmarino]

@ndr-brt I'm fine with 1-3.

For core-spi/policy, I would move those to a new policy-engine-spi since they are an "engine" that uses the evaluator.

If I understand moving base-core/policy to the new policy-evaluator module correctly, that will wind up causing an issue b/c it will introduce SPI dependencies (e.g. ParticipantAgent). We would have to move those to an implementation module.

The AtomicConstraintFunction functions are at different levels. We should probably rename the one that references PolicyContext since it is at the engine level.

[ndr-brt]

@jimmarino So core-spi/policy could become spi/policy-engine-spi module and base-core/policy could become core/common/policy-engine module right?

After this the AtomicConstraintFunction renaming could become more obvious, I'll try this