Stop retrying get-workflow-history with an impossibly-short timeout

[Groxx]

Previously, when a GetWorkflow(...).Get(...) call timed out while waiting for the workflow to complete, this happened:

• N-1 requests of the default long-poll timeout occurred, and it correctly retried
• The final request would have something like 5 seconds left, so it performs that call
• The server gives up the request slightly before that timeout so it can return the next page token for a future request to use (as happened in the N-1 earlier requests)
• Since no history was received and there's still time left in the context (~50ms internally), another impossibly-short request was sent
• This request fails immediately with a "insufficient time for long poll request" error.
• This bad-request error is what is returned from Get(...)

Which is pretty clearly sub-optimal. Both because we sent a request that is almost guaranteed to fail, and because the error returned to the caller is fairly generic looking / doesn't describe what happened. It just looks like they sent us a bad request / their code is not reasonable somehow.

What happened is that we ran out of time. So this now returns a DeadlineExceeded error, like any other timeout, and does not cause that final request to occur.

---

These "impossibly short deadline" errors are still entirely possible, e.g. if we are given a context with only 25ms remaining, or 25ms longer than the default poll timeout.

It might be reasonable to eagerly return a timeout in these cases as well... but we don't currently have a way to know what the server's minimum time is. That might be fixable in the future though.

[Groxx]

I should add a test or three for this, and I think I might need a different error message (since I believe it's not guaranteed that it's due to waiting on the workflow, the database could've just failed to respond)... but this works well locally at least.

[coveralls]

Pull Request Test Coverage Report for Build 0181659a-c6f5-42c6-bd6b-0b78f8c7d72a

• 13 of 13 (100.0%) changed or added relevant lines in 1 file are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.01%) to 63.764%

---

Files with Coverage Reduction	New Missed Lines	%
internal/internal_task_pollers.go	2	81.43%
<!--	Total:	2		-->

Totals
Change from base Build 01815bd7-df81-4af6-8702-318ee71d3223:	0.01%
Covered Lines:	12395
Relevant Lines:	19439

---

💛 - Coveralls