Concurrency issues when updating value and tag in non-secrets storage

[esune]

Update operations in non-secrets storage incur in concurrency issues when multiple instances of indy-sdk try to read-and-update values and tags for a record.

Consider a kubernetes deployment made of multiple services hat use indy-sdk (e.g.: Aries agents) that are backed by the same wallet service (PostgreSQL). When 2 (or more) of the services read the record and determine that they need to update its value and tags, the first service to enter the update queue will be able to successfully complete the task, while the following attempts will fail with a indy.error.WalletItemAlreadyExists since the state has already changed in the storage.

indy-sdk appears to use separate calls to update value and tags for a given record, which could be part of the problem since there is no guarantee that the transaction involving an update for both properties will complete without the state changing on the storage (it is not an atomic transaction, and it should be since tags need to be updated every time the value changes).