Service resolution for the workflow

[antho1404]

Instead of defining an instanceHash workflows now accept service that can be the service hash or sid.

If the instance is present then we use the instance otherwise we use the service and test that the service exists. If it exists then we get the instance of this service (throw an error if there are multiple instances), otherwise, we start a new instance of this service.

This doesn't support the creation of an instance with predefined envs yet.

[krhubert]

I remember that some time ago we agreed that sid shouldn't be supported on engine site as it makes some resolution pbms and other pmbs too.

The decision was to keep sid in cli local database and use it, and the service list api is more used.

I would love to see a sid local database before going on with further sid support

[antho1404]

the resolution of sid is done by the cli here and if there is an issue on the resolution (because of multiple match) there is an error displayed that encourage to use the hash instead

e4af202#diff-595898b5510f3ae484d2b6a4a90047a8R39

Also a database of alias/sid would be great on the CLI but let's think about that in another PR/issue and it might not be necessary if we have the service api with some filters

[krhubert]

the resolution of sid is done by the cli here and if there is an issue on the resolution (because of multiple match) there is an error displayed that encourage to use the hash instead

Resolution yes, but sids are taken from the engine still. The previous discussion was about abandoning sid in the engine, but this PR introduce more connection with engine and I think this should be the first step to finally get rid of the sid on the engine side. Except that LGTM :)

[NicolasMahe]

looks good but the error should be improved to give the reason how to fix it.

[NicolasMahe]

the resolution of sid is done by the cli here and if there is an issue on the resolution (because of multiple match) there is an error displayed that encourage to use the hash instead

Resolution yes, but sids are taken from the engine still. The previous discussion was about abandoning sid in the engine, but this PR introduce more connection with engine and I think this should be the first step to finally get rid of the sid on the engine side. Except that LGTM :)

The Engine is not compatible with SID like before. SID is just a parameter of service. The cli (using an helper from mesg-js) is doing the resolver itself by listing services... This will be easily transformable to a local CLI's database 👍

[NicolasMahe]

looking good 👍