[Security Solution] Value list not properly updated when the file already exists

[MadameSheema]

Info:

• Found during testing on 7.9 branch
• Commit: 79a311a

Preconditions:

• To have a value list already uploaded.

Steps to reproduce:

1. Go to Security > Detections
2. Click on Manage detection rules
3. Click on Upload value lists
4. Upload a file with the same name as the previous one uploaded and a different content

Current behaviour:

• The toaster displayed informs you that the file was properly uploaded
• The Upload Date is not updated, what reflects that the file was not uploaded or updated

Expected behaviour:

• TBD

Commented on 18th Aug by @spong:
Note Upload Date is not updated as it references created_at which will not be updated. So we potentially want to use updated_at instead/in addition. Additionally, these new list items will not be de-duped.

[yctercero]

Updated the ticket tags to remove bug as there isn't a bug in functionality, but an update needed to this modal to improve user experience.

@spong referenced this in the ticket details, but to go into it a bit more in depth for context... Large value lists are composed of the parent list document and the child items (each individual documents). When a list with matching title and type is uploaded, it appends those items to the existing list, NO updates are made to the parent list document. That means, that just by viewing the parent list document, you cannot tell that items were added, deleted, etc. Even exposing the updated_at date would not give the user any more context in this scenario.

We need to revisit large value lists to determine what changes might be needed. A few notes:

• Per the larger Kibana pattern, this modal should probably be moved to a flyout
• Users should be prompted that a matching list was found and asked if they want items appended (there's no deduplication done) or if they want a new list created
• Any plans on having a list management view? Right now the only place large value lists can be seen is in this modal.

cc @yiyangliu9286 @peluja1012