The Sonar way to define a constant

Give in. Make it a class, add a private constructor, use introspection in the unit test. Makes the code ten times as big. For a String constant.

This is the correct approach in general. You really do not want to create a "Constants" interface. The private constructor is needed to ensure that users do not inadvertently extend or instantiate an object that should not be instantiated.

How to add test coverage to a private constructor?

Create a list of exceptions. But doing this for each project may lead to long lists and invites people to add exceptions even for important stuff.

Too much work.

Deactivate rules. Now I would prefer not to tamper with the default profiles, because that may mean a lot of work on Sonarqube upgrades.

As you said... bad idea.

Create a profile that inherits from the default and overwrites things. It turns out that when you inherit from a profile you cannot deactivate rules. You can only add additional rules and change the configuration of rules (to lower their severity).

If you set the severity to "info" it will remove it from the Technical Debt calculation. I had to do that with squid:S1213 which is raised when I sort using the default order specified by Eclipse.