Configure staging and sandbox to pull tests from a aria-at-data-sandbox repo instead of aria-at

[mcking65]

We can't fully test the process in staging and sandbox because there is no way to:

1. Test how the system responds to new test plan versions.
2. Test how the system responds to edge conditions where test plans are in every phase of the working mode.
3. Test creation of issues from the app UI.
4. Test tracking of issues by the app.

To conduct this kind of testing, we need an equivalent to the aria-at repo where we can change the test plan data and github issues without consequences to the production aria-at data.

[howard-e]

1. Test how the system responds to new test plan versions.
2. Test how the system responds to edge conditions where test plans are in every phase of the working mode.

Agreed. The idea when mirroring the production environment in this instance was to make it easier for the differences to be understood between the prod environment, and to also check for any unexpected changes to existing behavior when using the same data. Ideally, the sandbox environment will always have sample data to support such testing like this in the future.

3. Test creation of issues from the app UI.

When being ran against the sandbox/staging environments, we can point this Bocoup's aria-at fork for testing this feature.

4. Test tracking of issues by the app.

Same as above

[howard-e]

3. Test creation of issues from the app UI.

When being ran against the sandbox/staging environments, we can point this Bocoup's aria-at fork for testing this feature.

4. Test tracking of issues by the app.

Same as above

When not being ran on production, bocoup/aria-at/issues will now be used as the source

[mcking65]

Moving to the ops project

[ccanash]

Closing as released on October 9th

[ccanash]

Reopening to address additional elements

[ccanash]

Most of this was addressed in #1301 . What is pending here is to write documentation on how how to get a dump of the production database to restore it on staging.