/delete/{id} should not return 404 if item missing (e.g., already deleted)

Issue details

See wallabag/android-app#375: when the deletion of an entry is queued for deletion in the app, but the entry has been delete (e.g., from the web interface) meanwhile, the app gets into an infinite battery-consuming loop trying to delete the no-longer existent item.

The root cause is that the /delete/{id} route returns a 404 (somewhat wrapped in a 200, for the GET) when trying to delete a non-existent entry. To better match with the semantics of the HTTP DELETE method, which should be idempotent in its response whether an object was deleted or not, this method should not return a 404, but a 200, whether an entry existed or not.

Environment

• wallabag-2.1.5
• How did you install wallabag? OpenBSD ports https://scm.narf.ssji.net/git/openbsd-ports/tree/www/wallabag
• php version: 5.6
• OS: OpenBSD
• type of hosting (shared or dedicated): dedicated
• which storage system you choose at install (SQLite, MySQL/MariaDB or PostgreSQL): SQLite

Steps to reproduce/test case

1. Add entry
2. Sync in App
3. Delete entry in web interface
4. Delete entry in app
5. Sync in App

-> The app keeps getting a 404 trying to delete the already-deleted entry.