Remove assign-to-new-keyword

[DanielNoord]

• Add a ChangeLog entry describing what your PR does.
• If it's a new feature, or an important bug fix, add a What's New entry in
  doc/whatsnew/<current release.rst>.
• Write a good description on what the PR does.
• If you used multiple emails or multiple names when contributing, add your mails
  and preferred name in script/.contributors_aliases.json

Type of Changes

	Type
✓	🔨 Refactoring

Description

Closes #4683

Ref. coverage drop in #5921

[Pierre-Sassoulas]

I don't know about this one, theoretically we could have new keywords in the future, so this is useless right now but it could become useful again. What about adding pragmas no cover ?

[DanielNoord]

I don't know about this one, theoretically we could have new keywords in the future, so this is useless right now but it could become useful again. What about adding pragmas no cover ?

#5921 (comment)

😄

I'm not sure. It's trivial to re-add this later on and I don't think new keywords are likely to be added as the language matures. I'd say remove for now. With DeletedMessage we make sure to save the message id if we want to re-add it later on.

[Pierre-Sassoulas]

Alright, if past me said so.. 😄

But yeah it's very unlikely that new keyword are introduced now (they reused from for raise Exception() from e instead of creating a new one. Let's merge !

[douardda]

It's been quite a while, but out of curiosity, how did @SoftwareHeritage swh-core get included as a sumodule here? (I randomly fell on this by finding a relation between pylint and swh-core in our big graph I was not expecting at all :-) )

[DanielNoord]

I think I was debugging an issue somebody reported with that module and forget to clean my tree when switching to this branch.