[exporterhelper] Reconsider the Go interface for the new exporter helper

[dmitryax]

I got feedback from a user of the new interface that having Export() function as part of the Request interface is pretty inconvenient if they need to pass a state between the calls like a client etc. Probably, we should consistently move towards functions instead of interfaces so users can provide methods of their custom exporter like myExporter.convert, myExporter.mergeBatches and myExporter.export if needed. The interface would be

func NewLogsRequestExporter(
	_ context.Context,
	set exporter.CreateSettings,
	convertFunc ConvertLogsFunc,
	exportFunc ExportFunc,
	options ...Option,
) (exporter.Logs, error)

cc @bogdandrutu WDYT?

[splunkericl]

+1 on this github issue. The issue we run into with the previous implementation is that:

• Request.Export is encapsulated by itself, the client used to export data needs to be wrapped inside Request
• Request needs to be marshalled and unmarshalled, it becomes more expensive as the client needs to be marshalled/unmarshalled. if the client maintains any states(i.e: TCP connection) it is gone.

The suggested pattern is similar to previous implementation, users can provide the function like:

client := newClient()
return NewLogsRequestExporter(ctx, set, converterFunc, client.Exporter)

So the client state is maintained