[Bug] Templating library has not been initialized when first requests are being served.

[StormyDragon]

Describe the bug
Templating middleware initializes request context in after_server_start handler however
at this point the server is already serving requests.

Screenshots

Traceback (most recent call last):
  File "handle_request", line 62, in handle_request
    SanicException,
  File "_run_request_middleware", line 28, in _run_request_middleware
    AnyStr,
  File "/app/.venv/lib/python3.10/site-packages/sanic_ext/extensions/templating/extension.py", line 50, in attach_request
    request.app.ctx.__request__.set(request)
AttributeError: 'types.SimpleNamespace' object has no attribute '__request__'

To Reproduce
Start the Sanic server and immediately make a request.

Expected behavior
When the server is ready to handle requests the context variable should already be set.

Environment
Google Cloud Platform / Cloud Run / docker image: python:3.10-slim-bullseye
Dependencies handled by Poetry

Jinja2 = "^3.1.2"
sanic = { version = "^22.3.2", extras = ["ext"] }

Additional context
__request__ is not a good name for this, it implies that it is a magic variable typically belonging to Python itself, PEP8 suggests never inventing new ones.
I am guessing the intent was name mangling, but that only works on class attributes when prefixed with two underscores.

Load the context with before_server_start handler instead?
On closer inspection it does not appear that __request__ is used at all and this whole initialization chain can be stripped out?

Mitigations

# I need templates: Reach into the `app._future_middleware` and fish out the broken function.
>>> app._future_middleware[0].middleware.__module__
'sanic_ext.extensions.templating.extension'

# I don't need templates: Initializing extensions manually without builtins, then picking the modules used.
>>> app.extend(built_in_extensions=False, extensions=[HTTPExtension, OpenAPIExtension])

[ahopkins]

Templating middleware initializes request context in after_server_start handler however
at this point the server is already serving requests.

That is not true. Requests are not yet being received when after_server_start runs. The server is running and is bound to a socket, but it is not yet receiving anything.

Start the Sanic server and immediately make a request.

Some sample code would be helpful.

I am guessing the intent was name mangling

Nope.

can be stripped out?

Yup. Functionality has been replaced and is now part of Sanic itself as of v22.6: Request.get_current()