curl error handling could be more robust

[KevinMGranger]

Currently, each curl error has its string retrieved and printed to standard error. While this is fine for simple cases, there's some problems with it:

• it's a global, mutable change, and cerr printing is not synchronized
• it's invisible the consumer of the library
• if the consumer wishes to ignore the error, it's unnecessary overhead
• for high-volume tracing, it can be extremely verbose.

If there's some sort of permanent error (e.g. an incorrect collector host), the default reporting period of 500ms is used, and there's at least 1 span per that period, that's 2 lines printed per second. Although it's not too much if you're looking at it in the terminal while testing, it adds up to 172,800 lines per day.

It would be nice if the client could handle these errors themselves. I don't necessarily know what that would look like, but there's two ideas off the top of my head:

• template out a function to call with the curl error handle
• allow a std::function to be given to receive the curl error handle

The first is more performant, but might result in making the library more verbose. I'd have to think about it and look at code more.

As a side note, we could consider trying to establish the connection to the collector immediately, so we know about the problem before the first span is sent.

[rnburn]

We did something similar with the LightStep tracer, where you can pass in an std::function to capture and redirect any logging output.