Improve documentation for local setup and testing

[ccostino]

In order to make it easier for folks to work on our AWS broker, we want to update and improve our documentation around the local setup and testing of the broker so that it is easy to get up and running quickly to perform maintenance or add new features.

Acceptance Criteria

• GIVEN updated documentation on local setup and testing instructions
  WHEN someone checks out the repo
  AND starts to work on the broker
  THEN they should be able to get the broker working easily locally
  AND be able to run existing tests easily
  AND be able to add new tests easily

---

Security considerations

• None; this is just improving our documentation on how to work with an existing open source, publicly available project

Implementation sketch

• Updated documentation on how to configure the project for local development: catalog and secret management, installing Go and Go dependencies, shell configuration, etc.
• Updated documentation on how to configure and run tests locally: how to set up testing with Go, how to run the current tests, how to add a new test, etc.
• Updated documentation on how to test broker changes within our platform environment(s) when performing integration or smoke tests
• Consider adding a dev script that we've been including in other recent projects (e.g., here, here, and here)

There have been a few revisions and updates to Go since this documentation was last looked at. We may want to make sure this works with recent versions, especially with consideration to updates in how Go testing works. If this requires more work than updating Go dependencies and changing a couple of references to modules/commands to run, we should write a separate ticket for that work.

Alternatively, Docker-izing this repo may be a better approach to this to help keep things up to date and easy to run locally.

[ccostino]

@cloud-gov/platform-ops, did I miss anything here or is there anything else specific to add?

[bengerman13]

@ccostino looks good to me.
It might be nice to follow the dev script convention we've been using on the greenfield python projects lately - see here, here, and here

[ccostino]

🤔 Speaking of the dev scripts, would Docker-izing this project make this work a lot easier, and easier on folks to work on it in the future? I don't have a good sense of how much extra work that would take, or if it would make sense to make that the focus of this ticket to help cut down on other work and having to write up a bunch of steps for local setup.

[bengerman13]

maybe
Personally, I prefer the non-dockerized versions when it's an option, since it makes it easier to attach debuggers and inform your IDE about the environment (packages, etc)
There is definitely a tradeoff, though, with speed of setup - with the docker setup, pretty much the only prereq and use case is that the script is run by a docker user.
I think the kibana_cf_auth_proxy dev script makes it really quick and simple to get up and running quickly, but it has to make more assumptions about your environment (mostly just available python versions)