Remove rule and typology descriptions from the result payloads out of every processor

[Justus-at-Tazama]

Story statement

As an Actio platform operator, I want to minimise the size of the interservices payloads, So that I can make the most of the implementation of Protocol Buffers to improve platform performance And so that I can minimise the operating cost of the platform

Acceptance criteria

1. Either remove rule and typology descriptions or replace verbose descriptions with a description code mapped to a language-specific lookup table
2. Replace rule "reason" descriptions with a description code mapped to a language-specific lookup table
3. Create an Arango query that can return an evaluation result with the descriptions added

Impact assessment

1. The purpose of adding the descriptions into a processor's result payload was to be able to achieve a human-readable evaluation result at the end of the process. Unfortunately, the additional "weight" noticeably impedes performance and cost-effective performance is currently a higher strategic priority. Omitting the description from the results is not terminal - there are a number of ways in which we can mitigate the issue of results legibility. Abstracting the descriptions also creates an opportunity to implement multi-language support for the evaluation results.
2. The rule executor will be impacted by removing the rule description (desc) and reason attributes from the rule results. All 300 current Postman tests will need to be refactored.
3. The typology processor will be impacted by removing the typology description (desc) from the typology result.
4. The change in predecessor processors will need to cascade down through descendant processors: rules -> typologies -> TADProc.
5. Any current (and future) CMS implementation must be updated to carry the responsibility for merging the descriptions and reasons into a display of the results.

[Justus-at-Tazama]

Clarifications:

• Completely remove the desc attributes from the ruleResult and typologyResult objects.
• The reason attribute in the ruleResult object should be defined as optional so that it can contain the description of any .err outcomes
• The reason attribute will be omitted entirely if the rule result is not an error condition.
• The lookup tables for the descriptions and reason codes will be hosted separately from the configuration documents (location to be determined). Lookup tables will be language-specific and will descriptions/reason codes will be merged into the reports in the CMS and based on the user's language settings in the UI. We will look for a suitable format to store and transport lookup information from the source (which should be hosted and maintained in EKUTA) - https://en.wikipedia.org/wiki/XLIFF was recommended.