Move almost everything out of autospotting.go

[gabegorelick]

This moves most code from autospotting.go to main.go and adds more tests for the latter.

See #406

Issue Type

• Feature Pull Request

Summary

Move code out of the main package and add some tests.

Code contribution checklist

1. I hereby allow the Copyright holder the rights to distribute this piece of
   code under any software license.
2. The contribution fixes a single existing github issue, and it is linked
   to it.
3. The code is as simple as possible, readable and follows the idiomatic Go
   guidelines.
4. All new functionality is covered by automated test cases so the overall
   test coverage doesn't decrease.
5. No issues are reported when running make full-test.
6. Functionality not applicable to all users should be configurable.
7. Configurations should be exposed through Lambda function environment
   variables which are also passed as parameters to the
   CloudFormation
   and
   Terraform
   stacks defined as infrastructure code.
8. Global configurations set from the infrastructure stack level should also
   support per-group overrides using tags.
9. Tags names and expected values should be similar to the other existing
   configurations.
10. Both global and tag-based configuration mechanisms should be tested and
    proven to work using log output from various test runs.
11. The logs should be kept as clean as possible (use log levels as
    appropriate) and formatted consistently to the existing log output.
12. The documentation is updated to cover the new behavior, as well as the
    new configuration options for both stack parameters and tag overrides.
13. A code reviewer reproduced the problem and can confirm the code
    contribution actually resolves it.

[codeclimate]

Function handler has a Cognitive Complexity of 21 (exceeds 20 allowed). Consider refactoring.

[gabegorelick]

@cristim My hope was to get as much moved out from autospotting.go and then get everything covered by unit tests in preparation for landing larger changes, like the event-based instance replacement, more safely. But there's still a lot of untested code so I'm not sure if this actually helps or just introduces more chances for regressions.

I'm open to suggestions for how to increase test coverage further. I see some old discussion on #172, but curious to hear your current thoughts.

[cristim]

Thanks for moving this forward.

I think at some point after merging a number of harmless/easy hunks we'll end up with a large chunk that we'll have to merge at once.

I think I prefer to have a larger jump with regressions that we then address quickly instead of an extended period of maybe more subtle regressions.

[codeclimate]

Code Climate has analyzed commit 257e09b and detected 1 issue on this pull request.

Here's the issue category breakdown:

Category	Count
Complexity	1

View more on Code Climate.

[cristim]

@gabegorelick I just merged the event-based PR a few days ago, would this PR still be relevant if we can rebase it on top of the current code or can we close it?

[cristim]

@gabegorelick are you still interested in contributing this?

There were lots of code changes since this was submitted so perhaps some of this doesn't make sense anymore.

[gabegorelick]

are you still interested in contributing this?

Sorry, I probably won't have time.

[cristim]

No worries @gabegorelick, I'll look into it within the next few weeks and try to port to the current code what still makes sense from this work.