Add context-aware functions to vault/api

[averche]

Credits

This pull request is based on a community contribution #14152 by ilyakaznacheev and resolves #14070

Description

For each API wrapper function in vault/api, we are adding a context-aware equivalent. These new functions will have WithContext appended to their names.

Implementation Notes

One of the issues that I discovered in the original PR (#14152) is a potential context leak due to this piece of code inside RawRequestWithContext:

	if timeout != 0 {
		// Note: we purposefully do not call cancel manually. The reason is
		// when canceled, the request.Body will EOF when reading due to the way
		// it streams data in. Cancel will still be run when the timeout is
		// hit, so this doesn't really harm anything.
		ctx, _ = context.WithTimeout(ctx, timeout)
	}

To prevent context leaks, the timeout logic has been extracted out of RawRequestWithContext and into each ...WithContext wrapper (using withConfiguredTimeout helper). Additionally, since RawRequestWithContext is still used outside of vautl/api, its implementation has been moved into unexported rawRequestWithContext

See this comment for more details.

Testing

All existing tests that were calling vault/api functions have been switched to call WithContext equivalents with context.Background() passed in. Since WithContext functions invoke the regular ones, this change should increase code coverage without any negative side effects.

[digivava]

Whew, good work! LGTM, aside from some inconsistency in when the http.MethodGet is used vs the hard-coded "GET".

I am starting to second-guess whether adding such a large amount of duplicate methods is a better choice than just adding ctx to all the existing ones and bumping to a new major version (where breaking changes would presumably be expected)... but it's a little late for that now so we can rethink that in the new version of the client I suppose!

[averche]

Whew, good work! LGTM, aside from some inconsistency in when the http.MethodGet is used vs the hard-coded "GET".

Good point, I think I'll just revert all of the http.MethodGet / http.MethodPut changes and create another PR for that after this one. It's not a good to mix two things in one PR (especially a huge one like this).

I am starting to second-guess whether adding such a large amount of duplicate methods is a better choice than just adding ctx to all the existing ones and bumping to a new major version (where breaking changes would presumably be expected)... but it's a little late for that now so we can rethink that in the new version of the client I suppose!

This is meant as a stop-gap solution until we have a new shiny version. In the new version, we'll most likely default to context-only functions.