Support gs:// URI scheme in hammer

[roger2hk]

Towards #313.

[AlCutter]

I think adding weird vendor specific URL scheme support to the core of the client is a bit of a slippery slope. How about if we at least put the GSFetcher into its own package somewhere, so folks using the client won't depend on that package unless they actively import & use it to create fetchers?

We could also tidy up the hammer API a bit to make it easier for users of that package to decide which fetchers to use - e.g. loadtest.NewLogClient could be deleted and replaced with e.g. loadtest.NewRoundRobinFetcher(f []Fetcher) Fetcher and loadtest.NewRoundRobinLeafWriter(w []LeafWriter) LeafWriter. This would perhaps fit a bit more naturally with the existing signature of loadtest.NewHammer which tries to be agnostic about how fetchers and writers are actually implemented.

wdyt @roger2hk ?

[AlCutter]

(e.g. transparency-dev/tessera#647)

[roger2hk]

I think adding weird vendor specific URL scheme support to the core of the client is a bit of a slippery slope. How about if we at least put the GSFetcher into its own package somewhere, so folks using the client won't depend on that package unless they actively import & use it to create fetchers?

We could also tidy up the hammer API a bit to make it easier for users of that package to decide which fetchers to use - e.g. loadtest.NewLogClient could be deleted and replaced with e.g. loadtest.NewRoundRobinFetcher(f []Fetcher) Fetcher and loadtest.NewRoundRobinLeafWriter(w []LeafWriter) LeafWriter. This would perhaps fit a bit more naturally with the existing signature of loadtest.NewHammer which tries to be agnostic about how fetchers and writers are actually implemented.

wdyt @roger2hk ?

Sounds good to me. I've created a gcp package and moved GSFetcher into it. Thanks for the refactoring in Tessera hammer.

[AlCutter]

I think adding weird vendor specific URL scheme support to the core of the client is a bit of a slippery slope. How about if we at least put the GSFetcher into its own package somewhere, so folks using the client won't depend on that package unless they actively import & use it to create fetchers?
We could also tidy up the hammer API a bit to make it easier for users of that package to decide which fetchers to use - e.g. loadtest.NewLogClient could be deleted and replaced with e.g. loadtest.NewRoundRobinFetcher(f []Fetcher) Fetcher and loadtest.NewRoundRobinLeafWriter(w []LeafWriter) LeafWriter. This would perhaps fit a bit more naturally with the existing signature of loadtest.NewHammer which tries to be agnostic about how fetchers and writers are actually implemented.
wdyt @roger2hk ?

Sounds good to me. I've created a gcp package and moved GSFetcher into it. Thanks for the refactoring in Tessera hammer.

Will you make the same changes to the fork here in this PR, or as a follow-up?

[roger2hk]

I think adding weird vendor specific URL scheme support to the core of the client is a bit of a slippery slope. How about if we at least put the GSFetcher into its own package somewhere, so folks using the client won't depend on that package unless they actively import & use it to create fetchers?
We could also tidy up the hammer API a bit to make it easier for users of that package to decide which fetchers to use - e.g. loadtest.NewLogClient could be deleted and replaced with e.g. loadtest.NewRoundRobinFetcher(f []Fetcher) Fetcher and loadtest.NewRoundRobinLeafWriter(w []LeafWriter) LeafWriter. This would perhaps fit a bit more naturally with the existing signature of loadtest.NewHammer which tries to be agnostic about how fetchers and writers are actually implemented.
wdyt @roger2hk ?

Sounds good to me. I've created a gcp package and moved GSFetcher into it. Thanks for the refactoring in Tessera hammer.

Will you make the same changes to the fork here in this PR, or as a follow-up?

I'm going to propagate the changes in a separate PR after the one in Tessera is merged.