Default std async transport with dangling goroutine

[rollbar]

Default std async transport with dangling goroutine

[jessewgibbs]

@cog-qlik thanks for bringing this to our attention. We'll stick this into the backlog for future improvements in the SDK.

[rokob]

Yeah this is doable, it will require a version bump as it will be a breaking change because the new behavior would result in nothing getting sent until someone calls the init. There already is a constructor if you don't want to use the default one. The overhead of a single goroutine is pretty minimal. Perhaps we should make close on the transport actually close the channel which will terminate the range loop and therefore exit the goroutine. We can then add Close to the top level which will close the std one. Auto opening it just to have it closed is a tiny bit wasteful but that would be backwards compatible.

Yes, I realized that implementing a different initialization mechanism implies a breaking change. Leaving the importer package the ability to decide whether to run goroutines in the back or not is preferrable IMHO.

@rokob adding a Close() function to stop that dangling goroutine if the std transport is not required at least gives a way to get rid of the problem and, at the same time, it's a backwords-compatible change. It could be a good compromise.