fix(init): Initialize _jwt_cookie_name in AsyncQueryManager __init__

[xneg]

SUMMARY

We face an issue. After setting GLOBAL_ASYNC_QUERIES to True and switching back again to False we gain errors 'AsyncQueryManager' object has no attribute '_jwt_cookie_name'.
Stacktrace of this error:

File "/usr/local/lib/python3.7/site-packages/flask_appbuilder/api/__init__.py", line 85, in wraps
    return f(self, *args, **kwargs)
  File "/app/superset/async_events/api.py", line 92, in events
    async_channel_id = async_query_manager.parse_jwt_from_request(request)[
  File "/app/superset/utils/async_query_manager.py", line 162, in parse_jwt_from_request
    token = req.cookies.get(self._jwt_cookie_name)
AttributeError: 'AsyncQueryManager' object has no attribute '_jwt_cookie_name'

Initializing this field inside __init__ fixes this issue.

[codecov]

Codecov Report

Merging #22314 (b900a06) into master (aa97ba4) will decrease coverage by 0.16%.
The diff coverage is 100.00%.

❗ Current head b900a06 differs from pull request most recent head fb78033. Consider uploading reports for the commit fb78033 to get more accurate results

@@            Coverage Diff             @@
##           master   #22314      +/-   ##
==========================================
- Coverage   65.59%   65.43%   -0.17%     
==========================================
  Files        1847     1847              
  Lines       70333    70333              
  Branches     7702     7702              
==========================================
- Hits        46138    46020     -118     
- Misses      22197    22315     +118     
  Partials     1998     1998              

Flag	Coverage Δ
hive	?
mysql	78.04% <100.00%> (ø)
postgres	78.11% <100.00%> (ø)
presto	?
python	78.23% <100.00%> (-0.36%)	⬇️
sqlite	76.57% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
superset/utils/async_query_manager.py	80.41% <100.00%> (ø)
superset/db_engines/hive.py	0.00% <0.00%> (-85.19%)	⬇️
superset/db_engine_specs/hive.py	71.14% <0.00%> (-16.21%)	⬇️
superset/db_engine_specs/presto.py	80.16% <0.00%> (-7.65%)	⬇️
superset/models/sql_lab.py	72.83% <0.00%> (-1.97%)	⬇️
superset/connectors/sqla/models.py	88.52% <0.00%> (-0.80%)	⬇️
superset/db_engine_specs/base.py	81.25% <0.00%> (-0.32%)	⬇️
superset/models/core.py	90.27% <0.00%> (-0.24%)	⬇️
superset/utils/core.py	88.61% <0.00%> (-0.11%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[rusackas]

Looks perfectly straightforward to me, but I'll let this bake a moment, in case anyone sees some random risk with this.

[villebro]

IIRC this happens when you flip the flag but don't restart your Celery process. I wonder if there's other problems that arise if Celery isn't restarted after enabling GAC..

[xneg]

@villebro I'm not sure. We deploy the whole installation including celery workers as a service in Kubernetes and redeploy it all together. Maybe the problem is with the order of pods restarting.

[villebro]

The order shouldn't matter, as the celery workers use the same config as the web workers (if you're using the default helm chart).