Fix (and simplify) mass deletion of several tables

[DL6ER]

What does this implement/fix?

Fix (and simplify) mass deletion of DHCP lease, diagnosis messages, and local DNS/CNAME records

---

Related issue or feature (if applicable): see Discourse thread

Pull request in docs with documentation (if applicable): N/A

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)

Checklist:

• [x] The code change is tested and works locally.
• [x] I based my code and PRs against the repositories developmental branch.
• [x] I signed off all commits. Pi-hole enforces the DCO for all contributions
• [x] I signed all my commits. Pi-hole requires signatures to verify authorship
• [x] I have read the above and my PR is ready for review.

[DL6ER]

@yubiuser You are right, for this table only the "(and simplify)" part applies

[DL6ER]

@yubiuser looking at this, this is actually not a new bug but in fact a more general bug of our toast notification system. Previously, we printed a single toast for deleting multiple entries and updated this on success/fail. Now we print individual toasts but can only update the last one (due to this aforementioned limitation). I guess we need to cluster again but - as the deletion events get fired async and individually, I'm not actually sure what would be the best Javascript handling to actually report about errors or success.

[rdwebdesign]

Why do we need the initial blue message saying "Deleting message..." and then update the message?

I think we could simply show the final message (success or error).

[yubiuser]

I think we have all those "doing xxx" messages because on slower devices it might need some time before the operation finished and success/failure is displayed. So the users know their click triggered an action.

[rdwebdesign]

Hmmm... Do we need to update the initial message?

In other words: can we simply display one toast with the initial "Doing xxxxxx..." message and when the answer is received we display another toast with the final message (not updating the initial one)?

[yubiuser]

This should be fine I guess.

[rdwebdesign]

@DL6ER

You have a related PR (at least in part) where you made some changes to showAlert(). I think that changes were intended to fix the toast issues we are seeing above.

[DL6ER]

Oh, more than half a year ago PR which totall escaped me. Closing this one as it is a duplicate. I will port the changes into the older PR and rebase it on latest development-v6.