Implement Page Deletion Based on 'ToBeDeleted' Label

[Miker91]

This PR introduces a new feature that allows for automatic deletion of pages based on the presence of a 'ToBeDeleted' label.

Changes include:

1. Added a check for the 'ToBeDeleted' label in the metadata of a page.
2. If the label is present, the page is deleted using the DeletePage API call.
3. A fatal log message is generated upon successful deletion of the page.
4. This feature helps in automating the cleanup of pages that are no longer needed, based on the 'ToBeDeleted' label.

How to Test:

1. Apply the 'ToBeDeleted' label to any page.
2. Run the program.
3. The page with the 'ToBeDeleted' label should be deleted and a log message indicating the deletion should be generated.

Any suggestions, improvements are more than welcome since I have 0 experience with GO.

[mrueg]

How would this workflow look like? Is there a way you would add the label automatically?

Couple of thoughts on how it is right now:

• Use a prefix for the label, e.g. mark:ToBeDeleted
• Enable it via a config flag only --delete-pages, so folks don't accidentally delete pages.

[Miker91]

Sometimes people want to get rid of the confluence page managed by Mark.
This works just like any other label in the readme:
Adding
<!-- Label: ToBeDeleted -->
will cause the confluence page to be deleted.
Ewentually, when
<!-- Label: ToBeDeleted -->
is removed from Readme, page will be recreated.

[mrueg]

I see, I personally think mark should publish what is inside a given repository (I think synchronizing will be hard).

We could think of providing the option of a deletion-file. This could be a simple CSV file with the space and title of a page), that mark would use to delete old pages.

With the current implementation, if there's a page in your repository with that label, that means on every run of mark it would create the page just to delete it later again?

[c-p-b]

@mrueg

Would a simple --delete mode or flag or other workflow path be significantly outside of the scope of mark's design and intention? The way we use mark is by locking Confluence down and designating the git repository as the ultimate source of truth, so a way to purge all Confluence pages that exist in Confluence but not in git would be a great feature.

If something like that sounds sensible and aligned with what mark is intended to do, I would be happy to take a stab at an approach that might do something like that.