DeleteFlow: Do not always rebuild flow index from scratch

[hillu]

Filter out the deleted flow id, write index back to storage.

(If the index can't be opened, still rebuild from scratch.)

Close #4015

[scudette]

This is great! I was actually planning to debounce this operation using the notification service

velociraptor/notifications/notifications.go

Line 39 in c741cf9

1. The normal case - listener called before notification is issued.

This will ensure that rebuilding the index only occurs once every few seconds . Usually there are two use cases for deleting flows:

1. The user deletes the flow in the GUI - this needs to be synchronous because once the delete operation completes, the GUI will refresh the flows list and needs to see the flow removed from it.
2. A user deletes a lot of flows programmatically (e.g in VQL)- in this case we can delay the index rebuild to some future time where all the flows are deleted.

This solution is good because it removes a flow one at the time so it is synchronous but it might have issues with concurrent deletion because there is no lock. Rebuilding the index will always get a correct solution because it reflects the files that are on disk at the time the index is rebuilt.

Probably there is a cross over point where deleting a lot of flows will benefit from delayed rebuild of the index, deleting a few flows might be faster by rewriting the index incrementally. Ideally this decision can be propagated to the caller. Maybe replacing the really do it bool with a struct options which specifies if to delete synchronously or incrementally as well would allow us to be smart about how to delete in the most optimal way?