refactor the code by removing the complex parts and dividing the responsibilities

[ArturHamannRonconi]

Is your feature request related to a problem? Please describe.
The complexity of some parts of the code significantly reduces productivity and delays the understanding of the whole for new contributors

Describe the solution you'd like
The solution I thought to improve this has 3 steps

• Remove the ResponseHandler class
  • This class is responsible for building a response with a custom status code and a message, but there are many unnecessary things inside it that make the class gain greater complexity.
  • example: if you make a get request to /v1/register you will get a response similar to this

{
  "data": {
    "id": "69b97c37-8a3a-4f16-b230-dfaf05725cc5",
    "name": "Name Example",
    "picture": "",
    "email": "exampla@mail.com",
    "createdAt": "2021-05-31T00:19:03.006Z",
    "updatedAt": "2021-05-31T00:19:03.006Z"
  },
  "metadata": {
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
              eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
              SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
  },
  "entity": "user",
  "code": "success-created/user",
  "status": 201
}

but most of the options that exist inside it are not really useful for whoever is using the api, it is not necessary to send the user ID and neither his information because these are information that should be confidential or that the user already knows, neither there is a need to send the status code as this is already inherent in the response, and it is not necessary to send the entity used as this is information that only the internal code should know. After it's finished, the responses are expected to come only with the token in the body and the status code in the header.

• Decrease the responsibilities of the service and increase those of the controller
  • Currently, functions with the name service have many responsibilities, these responsibilities include receiving requests and returning responses, these are not the responsibilities of a service, on the other hand controllers are useless, a proof of this is that if you go in routes, import a service in place of a controller and use it within the route, this will not change anything and will continue to function normally

• Refactor the tests and files that imported the classes that were modified

Describe alternatives you've considered
I'll be working on it now, and I'll use the express-async-errors package to facilitate the error-handling process and remove the responsibility for services to return responses.