Ticket Key Leak in proposedTicketIDs ZSet

[alvin-7]

What happened:
A memory leak occurs with the proposedTicketIDs sorted set (zset) key in Redis when OpenMatch's CreateTicket is immediately followed by DeleteTicket, and the ticket is accessed by the Director before deletion is complete.

What you expected to happen:
Ticket keys should not be retained in the proposedTicketIDs zset once the tickets are deleted, to avoid memory leaks and data inconsistencies.

How to reproduce it (as minimally and precisely as possible):

1. Call OpenMatch's CreateTicket to create a new ticket.
2. Quickly follow up with DeleteTicket to delete the newly created ticket.
3. Concurrently, the Director fetches the ticket for matchmaking.
4. Once the Director completes the matchmaking process, it adds the ticket key to the proposedTicketIDs zset.
5. At this point, the ticket has leaked since there is no mechanism to remove the ticket key from proposedTicketIDs.

Anything else we need to know?:

1. The Redis deployment utilized is a standalone setup, version 5.2.0.
2. The Director conducts matchmaking operations in cycles every second.

Output of kubectl version:
Client Version: v1.27.2
Kustomize Version: v5.0.1
Server Version: v1.24.4-tke.11-rc1

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
TencentCloud

Open Match Release Version:
v1.5.0

Install Method(yaml/helm):
yaml