"xbutil reset" should always works, even with cloud boards

[ghost]

Xbutil should be aware of the specificities of the board on which XRT is running and be able to reset the board even if it is not an on-prem Alveo.

For instance:

• On AWS VT1, "xbutil reset" does not work and make the FPGA unusable. There is a doc somewhere in the Video SDK that say that the VT1 must not be reset. But in practice, it will be more user friendly that the xbutil command works on this board even if it does nothing in practice.
• On AWS F1, "xbutil reset" does not work. After some search it is possible to find that the board needs to be reset with AWS FPGA utilities, then the MPD service must be restarted and then, the user need to poll "xbutil scan/examine" until the board is ready. Not really straightforward. Again, it will be more user friendly if "xbutil reset" do the necessary steps.

On my use case, I have a code that runs various applications and reset the FPGA between them. This code is intended to works with all boards and XRT versions, so I need to handle all of theses specific case myself. I am not always totally sure what I am doing is the good thing, and I am pretty sure one day, something will break because the things to do changed.

It would be far better if Xilinx make xbutil aware of all of theses corner cases and users just call a single simple command. Xilinx knowns the specificities of its boards, users not.

[xuhz]

1. for aws vt1, h/w reset of board is impossible. 'xbutil reset' in user vm can still run, but it only does things like killing apps, but no h/w reset on board. In this case, the 'xbutil reset' behavior can be improved to return 'failure as not supported'
2. for aws f1, it is xilinx FPGA chip but not xilinx board, the mgmt lib provided by aws doesn't support hw reset on the board. There is a 'clear' api that can be used to clear xclbin loaded, but not h/w reset. So far, the 'reset' behavior on f1 is the same to that on vt1, that is, user can run 'xbutil reset', but no h/w reset happening. This can be improved also to make the reset return 'failure as not supported'

btw, on azure, the fpga board can be reset the way to Alveo. so basically the behavior difference is not on-premise vs cloud, instead, it is case by case