Make the relation between msgid and symbol 1:1instead of 1:N

[Pierre-Sassoulas]

Description

At the cost of forcing to rename the old symbol when you create an old_name. Making the couple msgid/symbol a 1-1 relation removes legacy functions and complexity in order to ease implementation and optimize performance in the MessageStore. It will also permit to have multiple messages with the same old name for #1164.

Type of Changes

	Type
✓	🔨 Refactoring

[coveralls]

Coverage increased (+0.02%) to 90.024% when pulling 4aa99db on Pierre-Sassoulas:message-store-refactor into 4bf6f03 on PyCQA:master.

[PCManticore]

There's a lot to review here, just wanted to mention that I'm in the progress of reviewing it, but it's going to take a bit.

[Pierre-Sassoulas]

Hi @PCManticore, thank you for taking the time to review this. I know it's huge, I could try to separate the style/lint issues from the main refactor if you want. I'm still working on simplifying the way the MessageDefinitionStore class works by using the new possibility of the MessageIdStore, so there will still be some changes even if they should be localized in the MessageDefinitionStore only. I also have performance tests results to provide once its done. I thougth of adding a regex check of the symbol so it's a string with dash and alphabetic non accentuated character only, but this will be cleaner if done later in another PR.

[Pierre-Sassoulas]

A rebase of the master branch broke the tests so I force pushed to go back to 0eeb6774 from 14 days ago. I hope the problem come from the master branch :D

Regarding performances, I tested by analysing the current pylint code, so it seems that results are not comparable because I call "is_enabled" more on the new pylint code (there is more class, with the new MessageId), I'll have to do a more stable test and take all function into account. Seems like it could be a little slower. Let's make #1164 works and then optimize performances later (I have some ideas, using msgid as hash instead of a MessageId for example)

[Pierre-Sassoulas]

@PCManticore, I'm going to take a look at the two failing tests in python3.5 this week, but apart from that, the pull request won't change anymore.

[Pierre-Sassoulas]

@PCManticore do you want me to break this one into multiple smaller merge requests?

[Pierre-Sassoulas]

@PCManticore I'm going to simplify this and create other merge requests for clarity.

[Pierre-Sassoulas]

@PCManticore I created #3040, #3041 and #3042 in order to make this one easier to review :)

[Pierre-Sassoulas]

@PCManticore, this one is ready for review. I can't make it significantly easier to review anymore, but I did not change the functional tests so the new message backend work as well as the one before. For now the performance are not better, but they will be after we merge #3013, see here for some performance analysis regarding this change.

[PCManticore]

Thanks @Pierre-Sassoulas ! This looks good to go for me, does it depend on any other PR? Let me know if that's the case.

[Pierre-Sassoulas]

Nice! It's mergeable as it is, then I'll update the two PR that depends on this one. We're getting closer! :)