Prefer Atomic Test UUID over calculated hash for Ability ID

[leba-atr]

Description

Currently, the plugin calculates a md5 hash over the JSON serialized test definition for a given atomic test and then uses the hash value as the id for the plugin. While this is fine for static datasets, Atomic Tests every now and then receive updates. These updates cause the md5 hash to change an any reference in Caldera to break (e.g. abilities referenced from the stockpile plugin, check the debug output of Caldera for current examples).

This PR introduces a breaking change in the way how this plugin generates ability ids. Instead of calculating a hash over the test data, this plugin now prefers to use the auto-generated unique UUID that each test is assigned. This also affects how one references Atomic abilities in Plugins like stockpile but also custom in Adversaries created manually via API calls.

Context: when creating adversaries via manual API calls, one cannot just use the Atomic test uuid to link Abilities with a given Adversary but instead the custom hash value must be retrieved from the API beforehand. This makes it more tedious than I expected to reference Atomic tests in custom Adversaries.

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

• caldera setup completes successfully
• all warnings from Stockpile plugin regarding missing abilities in adversaries are gone
• visual verification that especially the Stockpile adversaries contain only abilities which 'make sense' (see use atomic UUIDs instead of md5 hash stockpile#579)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

[elegantmoose]

We will need to marinate on this change. Not against it logically, but not sure of the fallout from the breaking change.

[leba-atr]

I thought about that for a minute yesterday evening and came up with an idea that would on the one hand not be breaking but on the other hand require refactoring in the main Caldera repository.

Roughly, the idea is as follows:

• store both the UUID and the hash sum
• when looking up abilities, the REST api call handler looks up the id from the request as uuid first; if nothing is found, the handler falls back to the hash sum
• alternatively, the api call handler could use a regex to check if the id is either a uuid (e.g. [a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}) or a md5 hash (e.g. [a-fA-F0-9]{64}) and then look up the requested object by the corresponding property

Maybe that opens another way forward with this MR.