Introduce shouldEncrypt in PutRequestOptions for clients to not encrypt self key/shared key data

[murali-shris]

Is your feature request related to a problem? Please describe.

• Currently isEncrypted in metadata is set to false even though data is encrypted.
• Client don't have control if they choose not to encrypt data for self key/shared key

Describe the solution you'd like

• Introduce a flag shouldEncrypt in PutRequestOptions which will be true by default
• New client can still see old data which can be encrypted with isEncrypted=false. Handle this scenario while decrypting

Describe alternatives you've considered

No response

Additional context

No response

[murali-shris]

@gkc
For self key /shared key, data will be encrypted but metadata.isEncrypted = false.
Once we merge the changes for this feature, there are two scenario while decrypting
i) new data - data will be encrypted. metadata.isEncrypted = true
ii) old data - data will be encrypted. metadata.isEncrypted = false

I have implemented the below approach for backward compatibility in GetResponseTransformer
i) if key is public, do not call decryption service
ii) if metadata.isEncrypted=true, call decryption service
iii) if metadata is not set or metadata.isEncrypted=false, try decrypting the data(may be old data). if decryption passes, then return decrypted value. If decryption fails, then return actual value.

https://github.com/atsign-foundation/at_client_sdk/pull/1398/files#diff-4565ef50d8f9949de083fc75b9212acc31ae9463627cac423497f138664565d3
Another implementation which I had i mind (but yet to implement). If decryption passes for scenario iii) update metadata.isEncrypted = true in metadata. So old keys with isEncrypted=false, will eventually be migrated.

Please let me know your thoughts

[gkc]

Discussed on call