Move constants out of global space into settings and schema

Instead of creating a class with constants, I'd suggest to use the configuration API.

As I suggested, instead of creating a new Class for these constants, I moved them to our settings as this is the best practice. I also did some other minor changes, here's an overview:

• Moved all constants defined on scheduler.module to config/install/scheduler.settings.yml
• Injected the ConfigFactory inside the SchedulerAdminForm
• Introduced a new helper method SchedulerArdminForm::setting($key) and SchedulerManager::setting($key) which loads $key from the settings file.
• Updated a codeblock in SchedulerManager::publish() as the reference to both the Exceptions was incorrect.

Added the schema definitions for the new settings.

Anyone who has some time to review this?

Thank you for your updates / fixes on this issue!

Here are my remarks on your questions;
a: The test doesn't fail because we don't test if these configuration variables are explicitly set. As you say, by default Drupal will return NULL if the configuration parameter doesn't exist. If we want to make sure that our tests fail as soon as we did some "weird" changes inside the configuration files, we will need to check each configuration parameter inside our unit tests. This can be done quite easily by looping through all our defined configuration paramaters (hard coded of course) and see if they don't return NULL when we try to load them via the configuration API. This will ensure us that our tests will fail as soon as we have some typos or other issues with these parameters.

b: This is a very good example of dependency injection (see https://www.drupal.org/node/2133171). In the SchedulerManager service, we are injecting the ConfigFactory so that we don't need to load the static class. As the ConfigFactory is probably already loaded by other (core) modules, PHP will consume less memory in order to load this class. This is because the class is already loaded inside the memory of the server. As you can see in scheduler.services.yml, we add @config.factory as an argument. If you take a look at core.services.yml you will find a service config.factory using the class Drupal\Core\Config\ConfigFactory. This is the class we are injecting inside our own custom class.
Now that we developed our own service called scheduler.manager, other services can make use of our service by adding @sheduler.manager as an argument in their *.services.yml file. When they do so, they will be able to make use of all our methods without instantiating the class from scratch. Dependency Injection is a design pattern used in various programming languages. More information on that can be found on WikiPedia.
The difference is minimal. \Drupal::config('scheduler.settings'); will actually try to load the service (container) if it is already existing. If it's not existing yet, it will factor a new service and load it into the memory. You can see this in /core/lib/Drupal.php:341. The best practice here is to use Dependency Injection.

c: I can't give you a clear answer on that (yet). I'd suggest that we create a new issue and discuss it over there as this will impact our end users.

Looks all good to me, RTBC!