[BUG] e2e tests are failing for go1.19

[npazosmendez]

The title says it all. Logs are not really helpful, we are seeing errors like this:

{"level":"error","ts":1659562531.3878303,"caller":"mockbackend/e2etesting.go:306","msg":"test failed","failures":[{"error":"failed to perform the request: Get \"http://127.0.0.1:8081/render/?format=json&target=percentileOfSeries%28carbon.api.%2A.cache_size%2C+95%2C+false%29\": EOF","errorVerbose":"failed to perform the request: Get \"http://127.0.0.1:8081/render/?format=json&target=percentileOfSeries%28carbon.api.%2A.cache_size%2C+95%2C+false%29\": EOF\n\nmain.doTest\n\t/home/runner/work/carbonapi/carbonapi/cmd/mockbackend/e2etesting.go:197\nmain.e2eTest\n\t/home/runner/work/carbonapi/carbonapi/cmd/mockbackend/e2etesting.go:302\nmain.main\n\t/home/runner/work/carbonapi/carbonapi/cmd/mockbackend/main.go:119\nruntime.main\n\t/opt/hostedtoolcache/go/1.19.0/x64/src/runtime/proc.go:250\nruntime.goexit\n\t/opt/hostedtoolcache/go/1.19.0/x64/src/runtime/asm_amd64.s:1594"}],"stacktrace":"main.e2eTest\n\t/home/runner/work/carbonapi/carbonapi/cmd/mockbackend/e2etesting.go:306\nmain.main\n\t/home/runner/work/carbonapi/carbonapi/cmd/mockbackend/main.go:119\nruntime.main\n\t/opt/hostedtoolcache/go/1.19.0/x64/src/runtime/proc.go:250"}

Note that the go1.19 check was added by the upstream and it's failing there too:
https://github.com/go-graphite/carbonapi/runs/7661338705?check_suite_focus=true

But they can still merge PRs. We can't, so we commented it out.

[Civil]

That should be fixed upstream by go-graphite#682 that.

Btw, not sure if I should open a separate issue about that, but I really like to start talking early with you about overall how to operate things. I mean if you want to do PRs back upstream about features you add (and if so - how we do that), maybe discuss in general direction you want to go, etc, etc. As Ideally I would want your fork and upstream to be compatible and not to have disputes about what we are going to do, etc, etc.

[npazosmendez]

Hello @Civil, thank you for pointing out that fix.

We are definitely interested in having that discussion. Can you please create a separate issue to track that?

[ywwg]

@Civil, Hi! Yes it is one of our primary goals to stay current and mergeable with upstream. Our team doesn't want to be maintaining an entire fork. We hadn't considered pushing back upstream but that would be wonderful -- we're in the middle of a project to improve coverage of graphite functions and that's something everyone could benefit from.

We're in the middle of a week of heads-down work right now, but we'll circle back after that's over and set up a time we can introduce ourselves and talk about what we're doing.

[Civil]

I've opened #71 to keep it contained.

But sure, whatever is best for you. I think for now I'm interested in a question if I should cherry-pick commits from your fork or wait for a formal PR as I wanted to tag a new release upstream at some point.

And everything else we can discuss later.

[ywwg]

I would say don't cherry-pick commits because it's a bit of a mess with squashing and merging. Hold off for now and we can work on putting something better together.