refactor: simplify scalers cache by removing getScalerBuilder method

[rickbrouwer]

@JorTurFer mentioned in #6739:

I'm wondering if we should get rid of getScalerBuilder directly, as it uses a read mutex inside but it can return a scaler that it's immediately closed just after returning it. There are some tricky conditions, so maybe we can start with this as suggested and iterate if needed

This PR improves the scalers cache implementation by removing the getScalerBuilder method and inlining its functionality directly in the methods that need it. This is refactoring. A good check is desired :)

Checklist

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

Relates to #6739

[JorTurFer]

I think that this makes the locks a bit more explicit, but checking the result, I don't think that refactoring the function will avoid the race condition that could be before (the case where something changes after the read lock because the write lock is signaled after checking the result of the read lock output, but I'm not sure if we should extend the read lock context either 🤔 ), so I'm not fully sure about if merging this we are improving the readability or making the code more difficult to read. @wozniakjan ?

[rickbrouwer]

I think that this makes the locks a bit more explicit, but checking the result, I don't think that refactoring the function will avoid the race condition that could be before (the case where something changes after the read lock because the write lock is signaled after checking the result of the read lock output, but I'm not sure if we should extend the read lock context either 🤔 ), so I'm not fully sure about if merging this we are improving the readability or making the code more difficult to read. @wozniakjan ?

Yeah, you are right that this refactoring does not fix the underlying race condition. It keep the locks at the same boundaries. It’s more to make the code more explicit about where locks are held and removing an abstraction layer.
I think that if we also wanted to address the potential race condition, we should hold the read lock longer during operations on the scaler. But that may have performance implications.

What do you think is the best approach? I’m also fine by closing the PR.

[JorTurFer]

WDYT @wozniakjan @zroubalik ?