Refactor TodoService

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

TodoService became quite messy and I think we should refactor it.

Here are my suggestions (just couple of examples, I didn't really dive into it yet), it can be further discussed here or in a merge request.

What seems so messy

The service is quite long, a lot of 1-2 lines method. There is quite a lot of code duplication - we have eg.

• new_issue + new_merge_request which both just pass arguments to new_issuable
• update_merge_request, update_issue -> update_issuable
• close_issue, close_merge_request, merge_merge_request, merge_request_push-> mark_pending_todos_as_done

Some other examples

• condition in method reject_users_without_access could be simplified or removed if we split the service
• filter_todo_users just passes arguments to reject_users_without_access (and unique them)
• create_mention_todos might be simplified as well

How we could improve it

• we have a Todo::Destroy module for destroying todos when a user looses permissions to the target
• we could introduce Todo::Create module for creating todos
• create Todo::Create::BaseService where we would include methods like create_todos, getting & filtering mentioned users etc
• create inherited classes as needed (eg. IssuableService, NoteService)