Fix: make query configure idempotent to support multiple drasi apply

[whiz-Tuhin]

Description

This PR fixes issue #308 where calling drasi apply on an already configured query would fail with a 500 Internal Server Error (409 Query already configured).

The fix makes the configure method in the query actor idempotent by:

• Detecting when a query is being reconfigured vs initially configured
• Shutting down the existing worker before updating configuration to prevent resource leaks
• Skipping reminder registration during reconfiguration since the reminder already exists in Dapr (re-registering causes an AlreadyExists error)

This change aligns query behavior with source behavior, which already supports idempotent drasi apply operations.

Testing:

• Applied a query configuration twice successfully
• Verified logs show "Query reconfiguring" on second apply
• Confirmed no errors related to reminder registration or worker conflicts

Type of change

• This pull request fixes a bug in Drasi and has an approved issue (issue link required).

Fixes: #308

[danielgerlag]

Thanks for your contribution.
If I understand this code correctly, it looks like the query will be destroyed and recreated when it is re-applied. This is not desired behaviour as the existing indexes and result set of the query would become invalid (corrupt) depending on how much the query has changed. Queries have to be immutable, so it makes sense to return a 409 conflict to the end user.