Feature: Implements on_app_init hook

[peterschutt]

on_app_init callbacks

Issue with the current PluginProtocol.on_app_init() system.

• The Plugin.on_app_init() callback occurs before route handler registration, so plugins do not
  have the opportunity to receive the handlers passed to the application before they are applied to
  the app.
• Certain application attributes have pre-processing applied to them on assignment to self.
  Therefore, if a plugin wants to manage or modify these attributes, the plugins need to perform this
  step of pre-processing, or at least understand it, before they can operate on these configuraion
  attributes. E.g., as_async_callable_list().
• Difficult to be confident in longevity of implementations. Simple things like order of
  configuration/attribute changes, or changes to wrapper objects in later releases may impact the way
  plugins need to work to operate on certain configuration values.
• We run the risk of a plugin that abuses internal apis in PluginProtocol.on_app_init() becoming popular and making a rod for our backs in terms of internal refactoring.

Proposed solution

• We construct a pydantic model of the arguments that the application object receives, called
  AppConfig. We already use the validate_arguments() decorator, that constructs a signature
  model to validate arguments passed to the app constructor, so this would just be replacing that
  validation with an explicit model.
• The arguments to the starlite constructor are used to instantiate this AppConfig object.
• After the configuration object has been instantiated with the parameters passed to Starlite,
  any handlers registered for on_app_config callback receive the AppConfig instance and must
  return it.
• Config callbacks are passed the AppConfig object in the order that they are passed to
  the Starlite constructor and must define their own behavior and recommendations for where the
  plugin should be inserted into the callback list.
• Benefit of this is that plugins can be built around the certainty of semantic versioning guarantees of
  the Starlite interface.

Proposed implementation

The implementation is totally backward compatible.

Registered on_app_config hook handlers must receive and return an instance of AppConfig.

The AppConfig object is first instantiated from parameters passed to Starlite.__init__(), and then passed to each of the registered hook handlers.

The resultant AppConfig instance is used to instantiate the application.

Removes the use of pydantic.validate_arguments() on Starlite.__init__() as the instantiation of the AppConfig object does the same thing.

There is a test to ensure that the parameters of the Starlite constructor are matched by properties on AppConfig.

There is a test that ensures all properties on the AppConfig object are accessed within the Starlite constructor.

PR Checklist

• Have you followed the guidelines in CONTRIBUTING.md?
• Have you got 100% test coverage on new code?
• Have you updated the prose documentation?
• Have you updated the reference documentation?

[lgtm-com]

This pull request introduces 1 alert when merging ed8c247 into c9387f8 - view on LGTM.com

new alerts:

• 1 for Unused import

[Goldziher]

LGTM.

Please update the docs before merging, and also add attribute comments in the AppConfig class.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication