Update protobuf struct CreateXXXRequest

[NicolasMahe]

Currently the protobuf struct CreateServiceRequest is accepting a definition.Service as first parameter. This is not the best as the data send to CreateServiceRequest are not exactly a definition.Service, the hash should not be present as it is calculated by the Engine, it makes the API a bit confusing. Also, we cannot pass directly the output of the command mesg-cli service:compile as it needs to be inside the key definition in CreateServiceRequest.

My suggestion is to update CreateServiceRequest to:

message CreateServiceRequest {
  string sid = 1;                                      // Service's sid.
  string name = 2;                                     // Service's name.
  string description = 3;                              // Service's description.
  definition.Configuration configuration = 4;          // Configurations related to the service
  repeated definition.Task tasks = 5;                  // The list of tasks this service can execute.
  repeated definition.Event events = 6;                // The list of events this service can emit.
  repeated definition.Dependency dependencies = 7;     // The container dependencies this service requires.
  string repository = 8;                               // Service's repository url.
  string source = 9;                                   // The hash id of service's source code on IPFS.
}

Make sure that other CreateXXXRequest messages are following the same pattern.

[NicolasMahe]

Be careful to also check the data (like https://github.com/mesg-foundation/engine/pull/1112)

[krhubert]

We can also check id hash is set and return an error od not empty

[NicolasMahe]

We can also check id hash is set and return an error od not empty

Yeah sure

But let's not do it now. Let's first implement Cosmos and see what constraint it provides and then adapt the API again.

[krhubert]

Also we can do the same strategy for Filters. Just use data type for a filter, eg:

• execution filter can accept execution and we can filter by all data
• same event filter
• instance filter

In every of this palce, we're going to redifine a message type, instead of using one defined in definition.

[antho1404]

Let's implement that. To summarize:

• "Create" apis should not receive definition (renamed in type)
• "Create" apis should only receive directly the data needed to create the resource
• We can, later on, add validation with tools like gogo proto