Fix for #199 - Proper delete of all descendant keys in tree during delete/empty bin operations

[MiguelGuedelha]

I've kept the single key delete in the interface for compatibility (it's a public interface on public services, so never know if someone on U13 decided to hook and use these methods by themselves)

U16 version of the package still uses the delete/DB storage, while the 17+ versions seem to store the value directly in the IContent only, and the DB is completely gone.

@jcdcdev U16 is already EOL so don't think we need to propagate this bug fix to it. And the 17 version shouldn't need any fix at all due to how the package changed how it works.

---

What this fixes:

• If a parent with multiple children/descendants is "deleted" (moved to Bin), and then said parent properly deleted from the Bin itself, both the parent and all its descendants will have it's related rows deleted from the ReadingTime DB
• If a global bin empty action is triggered, instead of just the "root" items in the Recycle Bin being cleaned up on the ReadingTime DB, all the descendants are also properly cleaned.

This should prevent Foreign Key constraint errors that would prevent the actions mentioned above from completing successfully.

Testing this is simple:

1. Take the current sample site and create + publish multiple copies of the homepage at the root of the content tree.
2. "Delete" one of these homes.
3. On the Recycle Bin, delete one of the children only, not the parent. Everything should work as normal, as those children have no descendants.
4. Now delete the home from the recycle bin. Before the fix this would raise a FK error, now it should work fine.
5. Delete 1-2 of the remaining home nodes from the published content tree.
6. Trigger a empty recycle bin action
7. Everything should work and delete as expected instead of throwing a FK error on the UI

I've kept the pagination to 1000 so it's not completely unbounded (int.MaxValue) in case, there's some really stinky bins somewhere using this package, that might drown the DB out from doing such an unbounded fetch, but it's also not ridiculously low (50-100) and risk slowing down the empty operation by too much.

[jcdc-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[MiguelGuedelha]

@jcdcdev Think your auto-assign action is broken

[jcdcdev]

Hi @MiguelGuedelha, thank you for such a high quality contribution!

This looks great to me 🦄🤘