refactor ASO label/annotation updates

[nojnhuh]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:

This PR refactors how labels and annotations applied generically to ASO resources are constructed to enable delete()-ing existing labels or annotations which is planned for #3525. Otherwise this change should be functionally equivalent.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

• cherry-pick candidate

TODOs:

• squashed commits
• includes documentation
• adds unit tests

Release note:

NONE

[codecov]

Codecov Report

Patch coverage: 85.71% and no project coverage change.

Comparison is base (38f68d0) 54.12% compared to head (fd23170) 54.12%.
Report is 24 commits behind head on main.

❗ Current head fd23170 differs from pull request most recent head fdf0610. Consider uploading reports for the commit fdf0610 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3733   +/-   ##
=======================================
  Coverage   54.12%   54.12%           
=======================================
  Files         187      187           
  Lines       18909    18917    +8     
=======================================
+ Hits        10234    10239    +5     
- Misses       8126     8128    +2     
- Partials      549      550    +1     

Files Changed	Coverage Δ
azure/services/aso/aso.go	92.78% <85.71%> (-1.31%)	⬇️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Jont828]

Why do we want to set labels and annotations back to nil? Would it make sense instead to call SetLabels() and SetAnnotations() only when existing == nil?

[nojnhuh]

Why do we want to set labels and annotations back to nil?

Because labels and annotations are both serialized with omitempty, the existing resource will never contain empty, non-nil values for either of those fields. This preemptively emulates omitempty for the values of parameters so when we calculate the diff just below these changes, we don't treat a non-nil and empty map as different from a nil one since they would both be serialized as nil.

Would it make sense instead to call SetLabels() and SetAnnotations() only when existing == nil?

Any update (when existing != nil) may require labels and/or annotations to be updated (like when we notice a resource needs to be adopted), so I don't think that would work in all cases.

[nojnhuh]

(squash reminder)
/hold

[CecileRobertMichon]

/assign @willie-yao @Jont828

[willie-yao]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 2ea8eeb4a1842a99c8c97ab5f2da157063a2e71b

[Jont828]

/lgtm

[nojnhuh]

(squash reminder) /hold

done!
/hold cancel

[nojnhuh]

/retest

[CecileRobertMichon]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: CecileRobertMichon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [CecileRobertMichon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment