Github Actions instead of Circle for SDK Tests + Remove SDK Docker containers for testing

@tzaffi commented on [Wed Aug 17 2022](https://github.com/algorand/go-algorand-internal/issues/2235)

**Context**

Currently the SDK's are running their tests on Circle. EG:
* [go](https://app.circleci.com/pipelines/github/algorand/go-algorand-sdk/305/workflows/61ea9c33-b10f-4d2d-9772-5c690d9ca032/jobs/1248)
* [python](https://app.circleci.com/pipelines/github/algorand/py-algorand-sdk/828/workflows/eca0fec2-dab2-45fb-8847-3e84a6833c76/jobs/3537)
* [js](https://app.circleci.com/pipelines/github/algorand/js-algorand-sdk/449/workflows/25e2996f-d027-44af-a2c5-a126832539af/jobs/2546) (special case because of the browser based tests)
* [java](https://app.circleci.com/pipelines/github/algorand/java-algorand-sdk/289/workflows/98f78770-acba-4283-9f1e-1a88c58dceec/jobs/565)

Following this recent issue https://github.com/algorand/algorand-sdk-testing/issues/221, each of the SDK's will be using the Sandbox for their algod/kmd/indexer/postgres environment. However, they are still each bringing up a docker container for the SDK themselves.

In principle, the Docker containers for each SDK is unnecessary, and each SDK can be built directly on the CI's VM and communicate directly with the Sandbox containers.

With this in mind, we have a good opportunity to migrate to github actions for the SDK's.

**What are you looking for?**
1. Investigate the feasibility of moving off circle to github actions for the SDK's (the biggest question mark for me is the javascript SDK)
2. Assuming step 1 shows that migrating to G.A. is feasible and advantageous, effect the migration.
3. Possibly at the same time as step 2, remove the dockerization of each SDK from the build (but maintain the reliance on the Sandbox docker containers)

**Why is it useful?**
We expect this to:
* speed up the builds
* improve maintainability
* reduce costs

---

@winder commented on [Wed Aug 17 2022](https://github.com/algorand/go-algorand-internal/issues/2235#issuecomment-1218097226)

Does this remove the use of docker entirely?

One downside to this is that it becomes more difficult to run these tests locally for one-off tests. In the past, I have occasionally appreciated being able to run tests without having to set everything up. Or even for small changes, I would do all development through the docker test environment.

---

@michaeldiamant commented on [Wed Aug 17 2022](https://github.com/algorand/go-algorand-internal/issues/2235#issuecomment-1218257704)

> Does this remove the use of docker entirely?

@winder No, I don't think so. Expanding briefly below though happy to discuss live to go deeper.

* We're focusing on containers like https://github.com/algorand/py-algorand-sdk/blob/develop/Dockerfile.
* With the disclaimer that I haven't fully researched usage, my _assumption_ is these containers are _only_ used in CI builds.
* I'm imagining we can speed up the builds by defining an equivalent Github Action (e.g. configures a specific Python version). And we can support local use cases via https://github.com/nektos/act.

---

@winder commented on [Wed Aug 17 2022](https://github.com/algorand/go-algorand-internal/issues/2235#issuecomment-1218404934)

Thanks for the clarification. In the past I have used `make docker-test` in place of setting up a development environment locally. I've also found it useful as a santity check to see if there are issues due to software I have installed compared to the versions used by CI.

It's a good point though, we can probably use standard containers which CI has cached to speed things up.

Food for thought, maybe worth a live discussion.