fix: stricter regex for reserved keys

[srieteja]

Closes #437

- What I did

• modified the regex for reserved keys such that there is an explicit check for keys (including public/private tag and pre/postfix atsigns).
• added a new variable in AtConstants for the key that stores the atsign's blocklist.
• previously public hidden keys (public:__somekey@atsign) was considered reserved key, which it's not. With the current changes, it will NOT be considered a reserved key.

- How I did it

• Divided the keys into 2 groups:

1. Keys that do not contain atsign (e.g. privatekey:at_pkam_publickey, _latestNotificationId)
2. Keys that contain atsign as prefix/postfix (e.g. '@'bob:shared_key'@'alice, public:publickey'@'alice)

• These twogroups have their own regex and all these regexes are joined using an "OR" operator

• Made sure that the visibility of each key (public/private/shared) is also explicitly mentioned in the regex

• Introduced a new method 'isPartalMatch()' in class Regexutil that does not require a full string match (only for reserved keys). This is required as the public/private part of the key is a lookahead and will not be matched as part of the key

- How to verify it

• positive and negative tests have been added to ensure that test reserved keys explicitly to ensure proper classification

- Description for the changelog

fix: stricter regex for reserved keys

[gkc]

Nice work!

I see atsign-foundation/at_client_sdk#1161 which demonstrates that at_client has / is being tested against this PR - very good. (Note: should test all packages which use at_commons to ensure no breakages anywhere else.)

However, it looks like we have a breaking change; the at_client PR testing shows that the current at_client will fail if using this version of at_commons. Please can you see if there's a reasonable way to avoid a breaking change? if not then we need to bump the major version of at_commons to 4

[srieteja]

The only way we could avoid a breaking change would be to have a secondary check using the old regex in addition to a check with the new one. This would preserve backward compatibility but at the same time undermine the new regex. What do you think @gkc ?
(Note: Purnima and I have tested these changes with all major packages i.e. persistence-secondary, secondary-server and at-client we are currently testing it with all the other consumers of at_commons)

[gkc]

The only way we could avoid a breaking change would be to have a secondary check using the old regex in addition to a check with the new one. This would preserve backward compatibility but at the same time undermine the new regex. What do you think @gkc ? (Note: Purnima and I have tested these changes with all major packages i.e. persistence-secondary, secondary-server and at-client we are currently testing it with all the other consumers of at_commons)

Thanks @srieteja - I think we should bump the major version.

[srieteja]

@purnimavenkatasubbu and I have completed another round of testing with buzz and onboarding_cli; everything looks good with the new regex. Also, I have increased the version to 4.0.0 and updated the changelog as part of 6816bf9.

[gkc]

LGTM - thank you @srieteja and @purnimavenkatasubbu