Add gotData and endOfProcess handlers

[velom]

Summary

Add two new handlers to track the processing:

1. Helper WithGotData allows to pass a function will be triggered on every processing data block.
2. Helper WithEndOfProcess allows to pass a function will be triggered when the whole processing going to be finished.

Checklist

Delete items not relevant to your PR:

• Unit and integration tests covering the common scenarios were added
• A human-readable description of the changes was provided to include in CHANGELOG

[CLAassistant]

All committers have signed the CLA.

[Garbett1]

What's the difference of gotData vs data? Other than the function signature?

[velom]

data is "internal" handler set by library itself during query start:

clickhouse-go/conn_query.go

Lines 67 to 84 in 46d2298

	var (
	errors = make(chan error, 1)
	stream = make(chan *proto.Block, bufferSize)
	)
	go func() {
	onProcess.data = func(b *proto.Block) {
	stream <- b
	}
	err := c.process(ctx, onProcess)
	if err != nil {
	c.debugf("[query] process error: %v", err)
	errors <- err
	}
	close(stream)
	close(errors)
	release(c, err)
	}()

[serprex]

Suggested change

	on.gotData()
	on.gotData(block)

why doesn't gotData take block?

[velom]

If you'd like to, I can add it

[SpencerTorres]

(I sent a response in Slack but I'll copy here for the record)

I looked at the code here, and I'm hesitant to make these changes since they feel very application-specific (to our internal app). I want to learn more about what the goal of these hooks are.

Specifically these things stand out:

1. Having hooks for data and gotData is confusing, the names need to be clearer. We could rename data to block and gotData to firstBlock (assuming the goal is to track the first block, or count blocks). Maybe we could rename data to some internal function like _data since it's the only one that is always overridden by the driver.
2. I saw the code suggestion to add *Block to gotData. I think this would cause some data races if the user had access to these outside of the driver, and so we shouldn't expose them.
3. endOfProcess can be renamed endOfStream since the server packet is called EndOfStream. This depends on whether your goal is to track the end of processing, or the actual EndOfStream packet.
4. Do we need endOfProcess to know if a query ended? This should already be detectable through the responding driver.Rows return value.

Overall I want to make sure we aren't adding a solution to something really specific for one application. If we add it we need to test/maintain it, and I am suspicious about these lower level hooks. I feel like there's another way to expose these events, perhaps in the driver.Rows interface.