GEODE-6011: Prevent synchronization using strings and boolean

[nabarunnag]

* Locking is now achieved using reentrant locks as they are more fair than synchronization.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

• Has your PR been rebased against the latest commit within the target branch (typically develop)?

• Is your initial contribution a single, squashed commit?

• Does gradlew build run cleanly?

• Have you written or updated unit tests to verify your changes?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.

[jake-at-work]

@nabarunnag any thoughts on using an autoclosable wrapper and using with resource to guard these locks?

[nabarunnag]

@pivotal-jbarrett Thank you for your suggestion and I felt that it was a good idea to get the lock under a TWR.
But after going through all the articles and Java's Project Coin's decision to not include the locks as TWR, one of which was creating the instance every time something needs to be locked, I am planning to use pure reentrant locks for this PR. Maybe, if needed, we can create a new JIRA to implement this feature in a broader scope of the project rather than just two files.

[jake-at-work]

@nabarunnag Good point on the object creation overhead. Been in C++ land so long I didn't even think about that cost of RAII in Java.

[galen-pivotal]

typo: should be registerFunctionLock

[jake-at-work]

😄 good catch!