feat: do NOT add delete entries in commit log when expired keys are deleted

[srieteja]

closes #1660
- What I did

• Do not add CommitEntry for Delete Op on expired keys (disabled for now, will be enabled later)
• Introduced an optional param in scheduleKeyExpireTask() called runInterval which takes Duration and schedules the expiryTask at this timeInterval. (This is an improvement as previously this method would accept only time in mins and in type String)

- How I did it

• Introduce an optional named param in deleteExpiredKeys() called skipCommit, this decides whether a commit should be skipped when an expired key is deleted. [defaults to false; meaning commit will be created]
• Based on the method param above, set the skipCommit flag while calling remove() from deleteExpiredKeys() [in hiveKeyStore and notificationKeyStore]

- How to verify it

• new unit tests added should verify the behaviour of expired keys w.r.t. the changes

- Description for the changelog

feat: do NOT add delete entries in commit log when expired keys are deleted

[gkc]

@srieteja We have a chicken and egg scenario here; until we can be sure that most apps are using the latest AtClient, those clients will still be dependent on the commit log and sync responses to trigger deletion on the client side.

Therefore for now we need to

• add a flag to the atServer's config for this feature, defaulted to false (not enabled) for now
• and add a way of setting that flag dynamically for testing purposes (add it to ModifiableConfigs, add a subscriber somewhere, etc etc)
• and modify tests so they verify both the current behaviour with the flag not enabled, and the new behaviour with the flag enabled
• and add a test to assert that the flag is by default not enabled

At some time in the future, we can change the config to enable this feature by default. I'd suggest create a ticket for that and reference that new ticket in the description of #1660 and we'll keep assigning the ticket to the "sprint after next" until we think we're ready to go.

Make sense? cc @murali-shris @sitaram-kalluri

[gkc]

See comment I left

[srieteja]

Added flags in hive_manages/scheduleKeyExpiryTask() and hive_keystore/deleteExpiredKeys() to enable the feature being written in this PR. Also introduced config in AtSecondaryServer/AtSecondaryConfig and passed the same to the hive_manager/keystore to enable the feature in the PR (see #1727)

[srieteja]

I have tested the functionality and how this feature interacts with the client. @purnimavenkatasubbu has tested this along with #1727 and atsign-foundation/at_client_sdk#1187 with buzz and wavi. Everything seems to be working fine, Ready to be reviewed

[gkc]

@srieteja in the PR description you say that you

• set the skipCommit flag to true in deleteExpiredKeys() [in hiveKeyStore and notificationKeyStore]

that is only true for notificationKeyStore. In hiveKeyStore deleteExpiredKeys takes an "optimizeCommits" flag

[gkc]

LGTM. Nice work on the tests

[gkc]

@srieteja in the PR description you say that you

• set the skipCommit flag to true in deleteExpiredKeys() [in hiveKeyStore and notificationKeyStore]

that is only true for notificationKeyStore. In hiveKeyStore deleteExpiredKeys takes an "optimizeCommits" flag

@srieteja Please can you correct the PR description so it is accurate

Requested change was addressed

[srieteja]

Updated the PR description @gkc