New conf test scenario for state stores: transaction order

[artursouza]

Describe the proposal

As per #1209, CosmosDb implementation does not respect the order of transactions. This was caught as we changed our E2E tests on AKS to use CosmosDB and one of the E2E tests covered this scenario while our conformance tests don't.

This proposal is to add the following scenario to conformance tests for state stores and fix the state stores that do not pass this test:

1. Invoke Transaction API with the following operations in order:

  upsert key1 value1
  delete key1
  upsert key2 value2
  delete key3
  upsert key3 value3

2. Validate key1 is not present.
3. Validate key2 is present.
4. Validate key3 is present.

[shubham1172]

/assign

[shubham1172]

Per the conformance tests run in https://github.com/dapr/components-contrib/runs/5177659685 and local testing, some results for transactional state stores:

Name	Status	Result	Notes	Issue
Azure CosmosDB	Stable	Fail	Fails because key1 is present on alternate runs.	#1209
Azure SQL Server	Stable	Fail	Deletion is always attempted before upserts, and fails with message delete affected only 0 rows, expected 1	#1505
MongoDB	Stable	Pass	-	-
MySQL	Alpha	Fail	Deletion is always attempted before upserts and fails because key1 is present.}	#1521
PostgreSQL	Alpha	Fail	Same as MySQL	#1522
Redis	Stable	Pass	-	-