Move basic e2e tests to new e2e and add upgrade scenario

[OliverMKing]

Description

• Moves a few tests to the new testing framework.
• Adds framework for testing different operator versions and configurations
• Swaps around a few things that weren't working (like how we track things happening in private clusters with the aks invoke api). AKS invoke api isn't good for long running operations.

What's left for e2e

• Need to move a few more tests over (trivial since tests are fully working here)
• Need to setup GitHub Action workflow to run tests
• Add a little more documentation to how to use it after GitHub workflow is done. Add notes to release steps for adding new releases here.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Tested locally. You can too by running

cd testing/e2e/
go run ./main.go infra --subscription=<subscription> --tenant=<tenant> --names="basic cluster"
go run ./main.go deploy

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[coveralls]

Pull Request Test Coverage Report for Build 6164919630

• 5 of 5 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 88.949%

---

Totals
Change from base Build 6089997898:	0.02%
Covered Lines:	1964
Relevant Lines:	2208

---

💛 - Coveralls

[jaiveerk]

very much left to go through but wanted to post these before the weekend.
excited to look through the rest!

[OliverMKing]

/ok-to-test sha=b43d23b

[jaiveerk]

lgtm for the most part, only request is if we can clean up test setup/running suites with different configs (even if that means, for instance, adding operator deploy scenario as an operator config or something else to consolidate information there)

[jaiveerk]

absolutely love how thorough the documentation/comments have been throughout this PR - would you mind adding some brief descriptions here too? I think this is definitely a great practice that we should begin enforcing on future PRs

[OliverMKing]

what exactly are you looking to be documented here? Tried to make it as self documenting as possible with the type system

[jaiveerk]

there are lots of types here and it's a bit confusing to keep track of all the casting/movement of information which I imagine will make debugging a bit difficult - is there any way we can clean this up? This was mostly inspired by all the different types used in testing/e2e/tests/run.go

[jaiveerk]

realistically I'm not sure how exactly this will take place but happy to chat about what my specific pain points are - just a lot of mixes between lists and types that contain lists, similar names, etc etc - I just feel like it can be cleaner/that we can consolidate a lot of the information that is repeatedly moving around

[OliverMKing]

it's definitely a lot but using more times makes this simpler in this case. Using separate types to move information up means we can take away information making it easier to develop with.

If you can think of a specific way to improve this I'm happy to implement that in the future but this is the best I have for now.

[jaiveerk]

re: my comment in types... this is a lot

[jaiveerk]

approving changes per discussion/call