Enhancing Blueprint Lifecycle Order

[amarquard089]

Description
In the current implementation of Quart, both Quart.before_serving and Blueprint.before_app_serving execute simultaneously before serving the app, which aligns with expectations. However, certain scenarios may arise where Blueprint.before_app_serving relies on values set during Quart.before_serving. To enhance flexibility and decouple these processes, I propose either adjusting the execution order by running Blueprint.before_app_serving after potential Quart.before_serving or introducing a new method such as Blueprint.before_blueprint_serving.

This modification would allow for more intricate setups where dependencies between Quart and Blueprint lifecycles need careful handling.

Code to Reproduce

from quart import Quart, Blueprint, current_app

app = Quart(__name__)
bp = Blueprint("bp", __name__)

async def setup_clients():
    # setup clients like e.g
    app.config["Hello"] = lambda: print("hello world")

async def bootstrap_bp():
    # do something with the clients, e.g
    current_app.config["Hello"]()

app.before_serving(setup_clients)
bp.before_app_serving(bootstrap_bp)

Environment Details
Python version: 3.11.5
Quart version: 0.19.4

Expected Behaviour
No KeyError is thrown because bp.before_app_serving runs after app.before_serving.

Actual Behaviour
KeyError: "Hello" in bootstrap_bp.

Current Workaround
The current workaround involves changing bp.before_app_serving to bp.before_request. However, this solution may not be optimal for resource-intensive initializations.