[feature] Directory for an actor to store extra data that is managed by leapp

[fernflower]

Some actors may require to store additional information during the upgrade, which can be too big to put in the leapp-report files as is (example - the selinux actor and failed modules https://github.com/oamg/leapp-repository/pull/749/files#diff-7b3410d4a2f5284d190fcacc1cd90255b792a10baef32d37629158586277ffccR167-R170 )
Having this managed by actors themselves is not wise as those self-managed additional data files won't be archived\cleaned up in between runs together with other leapp logs - this situation is an invitation to fun debugging.

We could add some framework level LEAPP_BACKUP_DIR in the config with the possibility to override with a relevant env var, with '`/var/lib/leapp/backup' by default.

[vinzenz]

Backup is handled by the cli commands themselves

[fernflower]

@vinzenz 'backup' is probably a bad naming for the matter. It should be 'extra_actor_report_data' or smth. Some leapp-managed directory that will survive the upgrade and have actor-specific information stored so that we could actually include a path to those files in a report. Like https://github.com/oamg/leapp-repository/pull/749/files#diff-7b3410d4a2f5284d190fcacc1cd90255b792a10baef32d37629158586277ffccR167-R170

[pirat89]

Something like extra_resources or extra_actor_data sounds good to me. But we have to think about policies to store data inside. E.g.

• provide API to be able to store files inside?
• what will be the hierarchy? (we need to be sure that various actors are not randomly changing content created by a different actors; so e.g. /var/lib/leapp//extra/{repository}/{actorname}/... (probably not good, but for thinking.. also it could reflect dir strcture (path) inside repositories, so it could be like an extension of the private files for actors - if you know what I mean.)
• do we want to actors to read the content created by other actors? - i vote for the private policy. actor that created the content can read it, but for otheractors it should be unknown content. could be handled by API functions.