Add log data type support

[kkuzmin]

Solution Description

The following features are added:

• precompiled protobuf definitions for log data type.
• helper function al_log:buildPayload() for converting incoming log messages to protobuf payloads ready to be transfered to Ingestion service.
• HTTP request retry options. By default, two times retry for 5XX responses and system level errors.

[andrey-smirnov]

if it is possible to not include compiled pb js (azure can compile it by itself), please remove it.

[kkuzmin]

I was thinking of making a postinstall npm action but this will require too many magical scripting and looks like it doesn't worth it.
It is not guaranteed that the build machine has binutils or make installed - this is especially true for Azure where Azure deployment runs npm install on its own, potentially on Windows machine.
Anyway even if we have the postinstall script which compiles protobufs it still requires attention every time new protobuf file is added.
In general I think checking in precompiled protobufs is a safer and easier option for our use cases for both AWS Lambda and Azure Functions.

[andrey-smirnov]

Isn't it too much of a delay for lambda?

[kkuzmin]

Have just 2 retries here means that there will be one retry after 3 secs and another one after 9 secs.
By default, maxTimeout is set is Infinity. Just want to make sure that is anybody increases retries the maximum timeout would not exceed 30 secs.
Obviously we can change default retry strategy to something like:

    minTimeout: 1000,
    retries: 3,
    maxTimeout: 10000

Anyway the caller function is able to set its own retry strategy and here is just my best guess for default values. Any ideas are welcomed.

[andrey-smirnov]

I think we can reduce such timeouts to smaller values as advised by @motobob to something like 300/600/900

[kkuzmin]

Default retry timeouts changes to 300/2100/10000