Ignore append locks for compaction when using concurrent locks

[AmatyaAvadhanula]

When using the new concurrent lock REPLACE, compaction should not skip intervals locked by APPEND locks.
There was a check in place for the context value TASK_LOCK_TYPE.
This PR adds the check for the key USE_CONCURRENT_LOCKS and also adds a relevant test.

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[kfaraz]

Slightly reformatted for better readability since this condition has become a little difficult now.

Suggested change

	Boolean.TRUE.equals(lockFilter.getContext().getOrDefault(
	Tasks.USE_CONCURRENT_LOCKS,
	Tasks.DEFAULT_USE_CONCURRENT_LOCKS))
	|| TaskLockType.REPLACE.name().equals(lockFilter.getContext().getOrDefault(
	Tasks.TASK_LOCK_TYPE,
	Tasks.DEFAULT_TASK_LOCK_TYPE));
	Boolean.TRUE.equals(
	lockFilter.getContext().getOrDefault(
	Tasks.USE_CONCURRENT_LOCKS,
	Tasks.DEFAULT_USE_CONCURRENT_LOCKS
	)
	)
	|| TaskLockType.REPLACE.name().equals(
	lockFilter.getContext().getOrDefault(
	Tasks.TASK_LOCK_TYPE,
	Tasks.DEFAULT_TASK_LOCK_TYPE
	)
	);

You may also consider breaking up the condition.

final boolean isUsingConcurrentLocks = condition1;
final boolean isUsingReplaceLock = condition2;
final boolean ignoreAppendLocks = isUsingConcurrentLocks || isReplaceLock;

[AmatyaAvadhanula]

Thanks, I've broken up the condition.
I've also verified that the USE_CONCURRENT_LOCKS flag is being used wherever TASK_LOCK_TYPE is, and also that it supersedes the latter.

[kfaraz]

thanks for the fix, @AmatyaAvadhanula !