[feat] Interface for waiting on flush to complete

[ramosbugs]

The current client flush interface causes an asynchronous flush:

libhoney-rust/src/client.rs

Lines 122 to 133 in 2f7cdc8

	/// flush closes and reopens the Transmission, ensuring events are sent without
	/// waiting on the batch to be sent asyncronously. Generally, it is more efficient to
	/// rely on asyncronous batches than to call Flush, but certain scenarios may require
	/// Flush if asynchronous sends are not guaranteed to run (i.e. running in AWS Lambda)
	/// Flush is not thread safe - use it only when you are sure that no other parts of
	/// your program are calling Send
	pub fn flush(&mut self) -> Result<()> {
	info!("flushing libhoney client");
	self.transmission.stop()?;
	self.transmission.start();
	Ok(())
	}

That function returns once the stop event has been queued and the new worker has been spawned. It would be useful to have this interface (or another) return a future that callers can wait on in order to determine when the original queue has been emptied.

An example use case is for a serverless (AWS Lambda) function, where we need to flush the events to Honeycomb before the Lambda runtime suspends the execution environment until the next function invocation.

A straightforward solution would be for stop to create a oneshot channel and pass the sender into the stop_event, and return a future that waits on the receiver. The stop event handler can then send to the channel when it's done flushing. I'd be happy to contribute a PR to do this (I need it pretty badly for a project) if that approach seems reasonable or if there's another approach you'd prefer!

[ramosbugs]

btw I just open sourced an OpenTelemetry crate built on top of this crate! https://github.com/ramosbugs/opentelemetry-honeycomb-rs

[nlopes]

Thank you for opening this @ramosbugs. Will take a look this weekend time permitting.

[ramosbugs]

@nlopes: gentle ping -- any thoughts on the approach above?

[nlopes]

Hi @ramosbugs, apologies for the delay, haven't had the chance to look into this. The approach looks good. If you'd like to put in a PR before I get to this, please feel free.