The parent issue RHELC-1091 has the label that triggered autocreation of this subtask to track the relative story point estimation for the integration test part of the issue.

The parent issue description at the time of creation of this issue was:
For insights UI, we would like to render the messages in Tasks rather than merely having Tasks save the message that convert2rhel would give at the command line and then display that in the UI.  In order to do that we need to pass variable information in the assessment data for the server side to use.

Acceptance Criteria:

• ActionMessageBase gets a new attribute, {{variable_data, }}which is set from a new parameter to {}init{}.  variable_data is a dict. The default value of variable_data is an empty dict.
• This attribute is included in the dictionary representation of ActionMessage and ActionResult.
• The Action.set_result() and Action.add_message() methods each have a new parameter to take a dictionary containing the variable_data
• Wherever we call set_result() or add_message(), we look at the message we are returning and add the variables we use to construct that message to the variable_data parameter.

A little more information on the serverside:

I talked with Paul Wayper about this and this was his input on the serverside:

• We can store templates in the task to associate with the message keys from the json data.
• The template should preferably be jinja2.
• The template should render to markdown.
• Then the markdown can be rendered to html and passed on to the front end.
  • (There is already some parts of insights UI that uses markdown => html and other parts that render directly to html.  Paul would like this to standardize on markdown => html)
  • Note: Paul and I briefly discussed the security implications of displaying data from untrusted hosts (example: hosting company runs this on their customers VMs.)  Markdown might help by escaping things that would be raw html (although it looks like markdown supports embedding raw html).  There's also the  question of an untrusted machine sending back data that the person reading the messages from the insights UI would misinterpret and then do something detrimental.  No generic solution for that yet.
• Paul's back of the envelope thoughts on what fields would be needed to display were:
  • alert (this roughly maps to our status)
  • message (this would be a one line summary)
  • diagnosis (an explanation of what went wrong or what was tested)
  • remediation (steps to take to fix the problem)
• We've talked about the begin and end marker for the script to output to stdout.  The current playbook results parsing uses  `"task_results": {` and `PLAY RECAP *` although those should be easy to change for the bash worker.