install/upgrade: async operation (install jobs) phase 1

Implementation ticket based on OKAPI-804

Purpose

The purpose of the async install is to address the problem of long tenant init operations. While Okapi's HTTP client has no timeout for that operation, there are clients using Okapi and/or gateways between Okapi and a backend module which causes trouble and might give up on such long operations. The async install will only deal with the former problem. The latter problem will have to make each module work in an async fashion or use some other means of transport.

Approach

The install and the upgrade (//proxy/tenants/<tenant>/install and //proxy/tenants/<tenant>/upgrade) can be kept as they are with no changes to existing behavior. They are currently using POST to perform the operation. We'd like to do use the same method to initiate the async operation. It could be as simple as using a flag "async=true" as query parameter. The RAML definition will be "identical" for non-async and sync mode.. But of course what follows is "async" only.

Approach

IPOST with async=true, to install/upgrade will return a Location and the status of the install can be inspected with GET on the returned location.
DELETE to be used signal "abort" (termination) and remove info about install/upgrade operation.
When install is working, it will persist status updates in the Okapi DB. It should also persist after it's done - as far as calling module's tenant init. It could persist as long as Okapi is running (for the cluster).. and be removed when Okapi/cluster is removed.
To list all operations, since the cluster was started... it would be possible to use GET on the install/upgrade path... same as POST to initiate. Likewise DELETE on that path would remove info for all operations.

Implementation proposal
1. Extend //proxy/tenants/<tenant>/install and //proxy/tenants/<tenant>/install with async=true parameter
2. Extend https://github.com/folio-org/okapi/blob/master/okapi-core/src/main/raml/TenantModuleDescriptor.json with:
a. status field: running, done, error
b. errors array of objects (follow error schema}
c. Optionally warnings array of objects
3. Extend https://github.com/folio-org/raml/blob/raml1.0/ramls/tenant.raml with a schema for return body, the schema should include errors, status, warnings which will be merged by Okapi into the combined status response