Promisification of Juggler DAO methods for service integration

[b-admike]

Description

As part of weakly typed service integration for REST/SOAP and other services, LoopBack 3 connectors should have support for promises. This would let us use async/await. We'd like to change this.

Related to #1069

Acceptance Criteria

• Add promise support to https://github.com/strongloop/loopback-connector-soap,
  see https://github.com/strongloop/strong-soap/blob/master/src/client.js
• Add promise support to https://github.com/strongloop/loopback-connector-grpc,
  see https://github.com/strongloop/loopback-connector-grpc/blob/master/lib/grpc-connector.js#L108
• Add/modify tests to verify support for both callbacks and promises
• Update appropriate docs which mention the affected methods in READMEs/loopback.io if any
• Include a section in the monthly milestone blog post highlighting Promise and/or async/await support with our service connectors.

[raymondfeng]

We need to check the following connectors:

• loopback-connector-rest
  • See https://github.com/strongloop/loopback-connector-rest/blob/master/lib/rest-builder.js#L448
• loopback-connector-soap
  • See https://github.com/strongloop/strong-soap/blob/master/src/client.js
• loopback-connector-swagger
  • See https://github.com/strongloop/loopback-connector-swagger/blob/master/lib/swagger-connector.js#L275-L282
• loopback-connector-grpc
  • See https://github.com/strongloop/loopback-connector-grpc/blob/master/lib/grpc-connector.js#L108

[bajtos]

A bit of additional context. In theory, I see two possible approaches:

1. Improve service connectors listed above to support promise/await invocation of the DAO methods they are defining, see Raymond's comment above.
2. Modify DataSource implementation to automatically promisify (add Promise support to) all methods provided by connector's DAO. This can be tricky, because at DataSource level, we don't know which methods are async (and should be promisified) and which are sync (and should not be promisified).

Since a half of our connectors already support promises, adding promise support at connector level is pretty easy and promisification at DataSource level is tricky, I personally prefer the first approach - adding promise support in individual connectors.

I am proposing the following acceptance criteria:

• Add promise support to loopback-connector-soap
• Add promise support to loopback-connector-grpc
• Write a blog post showing how to use Promises and/or async/await with our service connectors. IMO, the blog post should mention all four connectors, even those that already support promises today, and provide example code for both LB3 and LB4.

For completeness, there is a fifth service-like connector loopback-connector-remote and it already supports promises ✅

[dhmlau]

@b-admike , I've updated the acceptance criteria according to @bajtos' comment above.
PTAL. If it's good, then please move it for estimation. Thanks!

[shimks]

I've added support for promises in strong-soap but I'm wondering whether I should add in a test case for promise support in the downstream package loopback-connector-soap as well. Otherwise, I would consider this task done.

One problem with adding the test case for said package is that the tests are failing on loopback-connector-soap, and that the test case would have to build on top of the failing tests (operations built from wsdl file are failing, and the tests need to utilize the operations).