Create a new common method to parse parameter from config

[dttung2905]

Hi team,
This is the first steps in a two-step refactor process. We will first create a new util function to parse parameter from config . Then we move each scalers to use the new method

Assumption:

• The input is always in string, hence the convertStringToType takes in 'raw' value of pameter as string and convert to whatever types we want
• if its an optional parameter and we can not find from any config, return an empty string
• if its an optional parameter and is a required parameters, we return a supplied default value

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added ( Missing out tests for convertStringToType method)
• Changelog has been updated and is aligned with our changelog requirements
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Relates to #5037

[github-actions]

Thank you for your contribution! 🙏 We will review your PR as soon as possible.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Learn more about:

• Our contribution guide

[JorTurFer]

This looks really nice!
Why did you added in aziure_log_analytics_scaler.go file? We should move it to scaler.go as it's something shared, or to utils package inside scalers.

I'd add also a check for detecting if the parameters has been set in multiple places (eg: metadat and auth) to at least raise a warning (I think that error is better but just in case...) WDYT @kedacore/keda-core-contributors ?

[dttung2905]

@JorTurFer I think scaler.go is a better choice. Initially, I tried to park it under pkg/util/helpers.go but encounter cyclic import. Wdyt ?

[JorTurFer]

I think scaler.go is a better choice

That's perfect!

Could you add a validation to ensure that the same key isn't read from different sources at same time? cloud that check be an overkill?

[dttung2905]

@JorTurFer is it a validation that we are looking at? From my understanding, validation will reject/ fail the new object while what I have in mind is just throwing out warning

[JorTurFer]

Yeah, I don't have troubles just with a warning at this moment, but I guess that notifying to users somehow that for instance, the key potato is present in trigger.metadata and also in triggerauthentication is useful to prevent issues when both have different values

[dttung2905]

Yeah, I don't have troubles just with a warning at this moment, but I guess that notifying to users somehow that for instance, the key potato is present in trigger.metadata and also in triggerauthentication is useful to prevent issues when both have different values

@JorTurFer I have made some changes that throw errors when users set values in more than 1 place. Could you help to take a look when you have some time?

[JorTurFer]

LGTM!
WDYT @zroubalik ?

[JorTurFer]

@dttung2905 , static checks are failing due some style issue: https://github.com/kedacore/keda/actions/runs/7187276659/job/19574505804?pr=5228

[dttung2905]

@JorTurFer thanks for pointing that out. I have fixed it and everything passed

[zroubalik]

Looking good, what if we go a step further and instead of parsing from string allow parsing from any type to allow things describe here: #2299 and proposed in this staled PR: #2364

[dttung2905]

@zroubalik could you help to give it another review when you have time?

[zroubalik]

Looking good, let's resolve the Changelog and merge this

[dttung2905]

I just realised one of my commit is dropped when I did the last rebase 🤦 . The commit was to address the feedback from @zroubalik #5228 (review). Hence, the current PR still only accept string type as an input instead of interface{} type. Really sorry for that as I did not check thoroughly 😮‍💨

I managed to recover the lost commit. Will author an PR shortly