cfgutils lock

[linuxmaniac]

Pre-Submission Checklist

• Commit message has the format required by CONTRIBUTING guide
• Commits are split per component (core, individual modules, libs, utils, ...)
• Each component has a single commit (if not, squash them into one commit)
• No commits to README files for modules (changes must be done to docbook files
  in doc/ subfolder, the README file is autogenerated)

Type Of Change

• Small bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds new functionality)
• Breaking change (fix or feature that would change existing functionality)

Checklist:

• PR should be backported to stable branches
• Tested changes locally

Description

expose in config via cfgutils core_case_hash optional second string key for hashing

[miconda]

I have nothing explicitly against this enhancement, but I guess that if one wanted to have two strings to compose the lock key, then could use lock("$var(str1)$var(str2)") as alternative to new variant lock("$var(str1)", "$var(str2)"). The hashing behind is probably not the same result, but from the perspective of taking in consideration two strings for hashing, should be a similar behaviour.