Increase plug-in manager functionalities

[SlnPons]

Context
Today, our plug-in manager has very limited functionalities. It can run a manually installed plug-in on a certain port and read some info.
The objective of this ticket is to extend its capabilities by allowing it to install, detect the status and uninstall plugins automatically.

User flow

1. User installs and runs Thyra
2. User accesses the plug-in manager page
3. From the plug-in manager page, user can

• Delete a plug-in that is already installed
  a. user clicks on the "delete" button
  b. user sees a pop-up from Thyra saying: are you sure you want to delete it? Yes / NO
  c. user clicks on "yes", plugin is removed from the page AND from his computer.

• Install a plug-in that exist
  a. user clicks on install
  b. user sees the plugin listed on the page
  c. user can clicks on "access" button and a new page to the plugin opened
  d. user can use the plugin

• see if a plug-in is
  ** Active: installed + in-use
  ** Inactive: installed + not in-use
  NB: not certain of the definition here but the idea behind active / inactive is for the user to be able to have some plugins installed but to not use them. For instance, they want to try 2 diff. wallet plugin they installed them both and decide to only use one after the other. - can be discussed!

How to

• Create separate logs for each plug-in accessible for the user interface and remove them from thyra-server. It's a plugin thing not a thyra-server to get these logs...
• Create script that automatically installed a plug-in on user's machine by clicking on a button
• Create script that delete installed plug-in from user's machine by clicking on a button
• Create a "plug-in status" in thyra plug-in manager that detects if a plug-in is in-use
• Create sequence diagram to explain and show how thyra interacts with plugins ⚠️

Technical details
Give the technical insights so anyone in the team can tackle the tasks - Dev

QA testing
Does this task require some QA tests ?
If yes, explain how to validate it

[gregLibert]

My suggestion is to construct the following API on Thyra side:

• /plugin/manager
  • POST: Install a new plugin
  • GET: List all installed plugins
• /plugin/manager/register
  • POST: Register a new plugin
• /plugin/manager/{name}
  • GET: Retreive plugin status and logs
  • DELETE: unistall plugin
• /plugin/manager/{name}/restart
  • POST: Restart a remote plugin
• /plugin/manager/{name}/stop
  • POST: Stop a remote plugin
• /plugin/manager/{name}/start
  • POST: Start a remote plugin

To work end-to-end implies to add some new functionalities on the plugin side:

• register to thyra
• exposing status
• stop and restart mecanism

[0xMazout]

What i would need from my side atm is when i call get plugin/manager to have per plugin :

Name : string : name of the plugin
Description : string : describe the plugin with a sentence to display it has a tooltip
Status : bool : is it ready to launch or not
Logo : string :Url to load the image of the plugin

[SlnPons]

See here exhaustive list of what the plugins will have to share with Thyra: #384

[SlnPons]

Hey @gregLibert

1. what's the difference between:
   GET /mgnt/plugins => retrieve the list of plugins
   and GET /plugin-manager => retrieve the list of plugins

2. I don't see the following endpoints created?
   /plugin/manager/{name}/restart
   POST: Restart a remote plugin
   /plugin/manager/{name}/stop
   POST: Stop a remote plugin
   /plugin/manager/{name}/start
   POST: Start a remote plugin

Why? Should we address them separetly? If we talked about it, sorry :/, I don't remember the rational behind not doing it now.

[gregLibert]

1. what's the difference between:
   GET /mgnt/plugins => retrieve the list of plugins
   and GET /plugin-manager => retrieve the list of plugins

/plugin-manager is the new plugin manager. I guess that /mgnt/plugins is the old version

[gregLibert]

2. I don't see the following endpoints created?
/plugin/manager/{name}/restart
POST: Restart a remote plugin
/plugin/manager/{name}/stop
POST: Stop a remote plugin
/plugin/manager/{name}/start
POST: Start a remote plugin

Why? Should we address them separetly? If we talked about it, sorry :/, I don't remember the rational behind not doing it now.

Yeah, no time to takle that. Sorry. To be done in another issue.