clear pending queue while manual flush request.

[IvanChupin]

This small fix clear the stuck in pending reroute task for particular flow during manual flush process.
We need to clear the pending queue for the stuck in progress reroute tasks in order to prevent later processing of theses outdated pending tasks, which leads to the similar errors in logs:
Could not reroute flow, error-description=No paths of the flow {{someFlowId}} are affected by failure on IslEndpoint(super=NetworkEndpoint(switchId={{some switch id}},
.
Here is the way how to test this fix locally on the virtual environment.

1)

First, let's simulate the problem on the virtual environment for the develop branch.

2)

Apply this patch onto develop branch, it contains some change that will catch first auto reroute task for particular flow with the name flow1_3 into in-progress queue :
stuckPending.txt

3)

Deploy env

4)

Now create the following flow:

  "flow_id": "flow1_3",
  "source": {
    "inner_vlan_id": 111,
    "port_number": 111,
    "switch_id": "1",
    "vlan_id": 111
  },
  "destination": {
    "inner_vlan_id": 333,
    "port_number": 333,
    "switch_id": "3",
    "vlan_id": 333
  },
  "maximum_bandwidth": 100,
  "path_computation_strategy": "COST"
}

Created flow would have path 1-2-3

5)

Now we want to trigger auto reroute for created flow. Set switch 00:00:00:00:00:00:00:02 into under maintenance mode and evacuate all the flows from it. This will trigger auto reroute for created flow, but applied patch will catch the reroute task on in-progress queue and will not allow the reroute algorithm to initiate and finish actual flow reroute.
Despite the fact that the flow status will be in "status": "Up", the flow reroute task stuck on in-progress queue. And any other forthcoming auto reroutes will not be executed, since they will be put into the pending queue.Also manual reroute api calls will fail (in kibana apply filter: loggerName is org.openkilda.wfm.topology.reroute.service.RerouteQueueService ).
In kbana we can see the logs corresponding the autoreroute:

Also we can make sure that the flow is stuck by calling manual reroute:

{
  "correlation_id": "d5e56cba-b30e-4612-a51e-7f8c45ee863b : now",
  "timestamp": 1746633062684,
  "error-type": "The request cannot be processed",
  "error-message": "Could not reroute flow",
  "error-description": "Flow flow1_3 is in reroute process"
}

And in order to put forthcoming auto reroute task into the pending queue(since in-progress queue is busy with stuck task) we need to trigger auto reroute once again, by turn-of maintenance mode and turn it on with flow evacuation again on the same switch.
It will make the system put auto reroute task into pending queue.
.

At this moment we have the following state for flow1_3:
in-progress queue has some task
pending queue also has some task, but pending queue can not be executed until in-progress task finish it's execution with success or failure. Since in-progress task will never be finished(because our patch, or on the prod env for some unforeseen reason) we need help with manual flush.

6)

Let's clear in-progress queue by calling appropriate northbound api: /v1/flows/{flow_id}/reroute/flush.
you will see the following log:
Process manual Flush Request for flow: flow1_3
For this moment we have the following state for flow1_3:
in-progress queue there is no tasks since it was flushed.
pending queue has some task, because they have not been flushed. (this task for reroute associated with affected ISL's on switch 00:00:00:00:00:00:00:02)

7)

Then let's set off under maintenance flag from the switch.

8)

Now we want to trigger auto reroute again. Set switch 00:00:00:00:00:00:00:02 into under maintenance mode and evacuate.
Let's explore the logs: (tip: also add thread filter with the value from any message that contains string flow1_3, because we need to filter out messages from the bolt which runs in parallel but did not intercept our request)

From the screen,
num 1 is the message which shows us the log for the "beginning" of the auto reroute process. Pay attention that we have inProgress=null, some pending task with affectedISL related to switch 2 and throttling which our latest and current auto reroute task.
num 2 is the message showing that we take current throttling task and put it to the in-progress queue. Did not touch pending at this moment. and we set throttling to null (did not fit on the screen for this message). Also in the end of this step we actually send the reroute request further into the system.
num 3 not really informative, but at this moment received some response for the last reroute.
num 4 same place as the previous message, but now we consider this response as successful auto reroute. (flow has been rerouted at this point and has completely new path

{
      "switch_id": "00:00:00:00:00:00:00:01",
      "input_port": 111,
      "output_port": 2
    },
    {
      "switch_id": "00:00:00:00:00:00:00:07",
      "input_port": 15,
      "output_port": 50
    },
    {
      "switch_id": "00:00:00:00:00:00:00:08",
      "input_port": 7,
      "output_port": 16
    },
    {
      "switch_id": "00:00:00:00:00:00:00:03",
      "input_port": 6,
      "output_port": 333
    }

)
num 5 now since we have some pending auto reroute tasks in the queue we will try to execute it. Despite the fact that we received success in the logs from the screenshot above, right after message num 5 , we actually failed.
And here is how:

9)

Copy correlation ID from the message num 5, open another kibana tab and filter by contextMap.correlation_id for copied cor id:

As you can see from the screen above, ValidateFlowAction failed with the error No paths of the flow flow1_3 are affected by failure on. Because pending task that has been executed contained outdated information about the flow.

10)

Now let's test all the same, but now we checkout to the bugfix branch and apply the same patch.
Repeat all the steps, but now after manual flush you will not see pending queue in the logs.
Also for the log mes num 5 the message should be Processing pending toSend:null
This log shows that there is no pending task to execute after successful reroute.

The same check could be applied to Y-flow with the name: flow897

Closes #5788

[yuliiamir]

Updated flush logic has been verified for regular flow/ y-flow and ha-flow.
Regular flow:
Both In_Progress and Pending queues are cleaned up when reroute/flush API is called as expected(no outdated reroute from pending queue)

Y-Flow:

Ha-Flow: