Startup fails if rule is moved to a different language

If a rule moves from language A to language B by declaring a deprecated key, SonarQube fails to start up.

The case can happen if a rule is moved to a different analyzer.

As an example, let's consider that the rule 'java:r1' is moved from SonarJava to SonarXml:

• SonarJava no longer includes 'java:r1'
• SonarXML includes 'xml:r1' with the deprecated key 'java:r1' and language 'xml'

At startup, after the new analyzers are installed:

• While registering the rules, SonarQube detects that 'xml:r1' is the new key for 'java:r1', so it updates it while keeping the same UUID.
• While updating active rules, it detects that a SonarJava built in quality profile no longer contains 'java:r1', and proceeds to deactivate it.
• When it deactivates 'java:r1', it checks that the rule has the same language as the quality profile. However since the rule was updated (and UUID kept), its language was changed from xml to java and the check will fail.

The same thing happens in the case where you downgrade, reintroducing 'java:r1' and removing 'xml:r1'.

Example of the error in the web process:

org.sonar.server.exceptions.BadRequestException: xml rule xml:S3822 cannot be activated on java profile Sonar way
  at org.sonar.server.exceptions.BadRequestException.create(BadRequestException.java:57)
  at org.sonar.server.exceptions.BadRequestException.create(BadRequestException.java:61)
  at org.sonar.server.exceptions.BadRequestException.checkRequest(BadRequestException.java:44)
  at org.sonar.server.qualityprofile.RuleActivationContext.doSwitch(RuleActivationContext.java:227)