Ensure we always have an integer when yum history tid is fetched

[Wescoeur]

We have had this trace in our Jenkins instance:

Jul 20 14:44:50 WARNING An error occurred in `exec_on_hosts_on_error_continue` for host 172.16.210.26
Backtrace:
Traceback (most recent call last):
  File "/home/vates/workspace/8.3 storage-main/lib/pool.py", line 64, in exec_on_hosts_on_error_continue
    func(h)
  File "/home/vates/workspace/8.3 storage-main/pkgfixtures.py", line 38, in <lambda>
    host.pool.exec_on_hosts_on_error_continue(lambda h: h.yum_restore_saved_state())
  File "/home/vates/workspace/8.3 storage-main/lib/host.py", line 322, in yum_restore_saved_state
    self.saved_rollback_id, '-y'
  File "/home/vates/workspace/8.3 storage-main/lib/host.py", line 57, in ssh
    decode=decode)
  File "/home/vates/workspace/8.3 storage-main/lib/commands.py", line 149, in ssh
    raise result_or_exc
lib.commands.SSHCommandFailed: SSH command (yum history rollback --enablerepo=xcp-ng-base,xcp-ng-testing,xcp-ng-updates The -y) failed with return code 1: Loaded plugins: fastestmirror
Bad transaction ID given
Error: Failed history rollback, no transaction

We don't have an integer during yum rollback here. Only a string: "The".
Because we don't know how this problem happens, it is interesting to make sure to always have an integer
when the transaction is started and also to throw an exception with the full yum command output in case
of problem.

[stormi]

A reminder about commit messages for fixes: they must describe the problem we are fixing. Here, an example scenario of when the tid may not be an integer.

[Wescoeur]

"for fixes" => Not really a fix. 👼