Update go-algorand internals to use Algod V2 API (No more V1 dependencies)

[barnjamin]

Problem

While digging into #2904 what it would take to support a remote API for goal, it was noted that some of the API calls currently only support the V1 API.

Since some public API providers no longer support the V1 API, in order to allow some remote endpoint for goal the API methods will need to be updated to allow V2 payloads.

Solution

Add V2 support to goal/libgoal

Urgency

Nice to have, may try to do it myself

Acceptance Criteria

Research issue.

Create followup tickets that lists the specific work involved in fully removing the V1 API references.

[algoanne]

@barnjamin I am labeling this "Team Scytale", and we will take a look through it during our grooming, but you are still more than welcome to work on it (I see you said you might). Until we put it in "In Progress", we are not yet actively working on it.

[michaeldiamant]

Here's a sample grep to gauge v1 API usage within go-algorand:

❯ grep -IlR "github.com/algorand/go-algorand/daemon/algod/api/spec/v1" .
./libgoal/transactions.go
./libgoal/libgoal.go
./cmd/algoh/deadman.go
./cmd/algoh/blockWatcher_test.go
./cmd/algoh/blockWatcher.go
./cmd/algoh/blockstats_test.go
./cmd/algoh/client.go
./cmd/algoh/blockstats.go
./cmd/algoh/mockClient.go
./cmd/goal/clerk.go
./test/framework/fixtures/restClientFixture.go
./test/e2e-go/features/stateproofs/stateproofs_test.go
./test/e2e-go/features/transactions/asset_test.go
./test/e2e-go/features/transactions/sendReceive_test.go
./test/e2e-go/restAPI/restClient_test.go
./shared/pingpong/accounts.go
./shared/pingpong/pingpong.go
./daemon/algod/api/algod.oas2.json
./daemon/algod/api/server/v1/handlers/responses.go
./daemon/algod/api/server/v1/handlers/handlers.go
./daemon/algod/api/swagger.json
./daemon/algod/api/algod.oas3.yml
./daemon/algod/api/client/restClient.go

[algochoi]

RE: Version affinity discussed in this comment

After sunsetting V1 algod APIs, it looks like versionAffinity in the client code can be sunsetted/deleted as well, and always return the V2 version of the algod response. Similarly, kmd does not need a versionAffinity because there is only one version (V1). If we were to create a V3 version of these APIs, then I think internal client code should be changed to reflect this instead of supporting two versions of it.