Stateless support for failed calls

[ColinBoisLydia]

Describe the bug

Due to built-in retries and given the way Go SDK catch failed calls to a Rudder stack, it is impossible to build a stateless application with delivery assurance.
At the moment,analytics.Client embed a Callback implementation where we don't have access to the internal payload of an analytics.Message given its signature:

// This interface is used to represent analytics objects that can be sent via
// a client.
//
// Types like analytics.Track, analytics.Page, etc... implement this interface
// and therefore can be passed to the analytics.Client.Send method.
type Message interface {

	// Validate validates the internal structure of the message, the method must return
	// nil if the message is valid, or an error describing what went wrong.
	Validate() error

	// internal is an unexposed interface function to ensure only types defined within this package can satisfy the Message interface. Invoking this method will panic.
	internal()
}

Thus, we cannot copy internal data into a cache DB nor retrieve an ID which could allow us to reconstruct an analytics.Message from data stored in a DB for instance. With this SDK implementation, we have to add a stateful internal retry queue in our services which can lead to data loss during a fast rollout

Steps to reproduce the bug
N/A

Expected behavior

I see two possible solutions:

• Add a method Data() to analytics.Message to let us copy the internal data to DB for instance (a builder method who ingest the output of Data() would be a huge plus)
• Add a way to communicate synchronously with a Rudder stack without using the internal retry-queue of the Go SDK -- I think it is the easiest solution

Screenshots
N/A

[pallabmaiti]

Hey, @ColinBoisLydia we would love to go on a meeting with you to understand the use cases here. Can I have your email so that I can send you invite or join our Slack channel?