Add ability to define custom tornado handler plugins

[philippjfr]

Allows defining custom Tornado handler plugins via the panel serve CLI.

[philippjfr]

pre-commit.ci autofix

[codecov]

Codecov Report

Attention: Patch coverage is 31.81818% with 15 lines in your changes missing coverage. Please review.

Project coverage is 82.18%. Comparing base (3c20154) to head (5e4bc6e).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
panel/command/serve.py	31.81%	15 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2752      +/-   ##
==========================================
- Coverage   82.21%   82.18%   -0.03%     
==========================================
  Files         339      339              
  Lines       51376    51398      +22     
==========================================
+ Hits        42237    42242       +5     
- Misses       9139     9156      +17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MarcSkovMadsen]

Is it possible to add and remove the handlers dynamically?

How does this compare to the REST API already supported?

Can a user use Async? How? I would probably prefer that.

How to get this to scale? Now you have Panel on web socket where you probable use num-procs and/ or num-threads?

What about oauth? Jwt tokens? Swagger api docs?

Would it be possible and better to build on FastApi?

[philippjfr]

Is it possible to add and remove the handlers dynamically?

Not with this PR no.

How does this compare to the REST API already supported?

This will let you build generic endpoints to do whatever you want unlike the REST functionality which is much more limited.

Can a user use Async? How? I would probably prefer that.

Tornado handler HTTP methods like .get can be synchronous or asynchronous, it's entirely up to you.

How to get this to scale? Now you have Panel on web socket where you probable use num-procs and/ or num-threads?

When using num-procs this endpoint will be duplicated across processes and the requests will be routed just like any other request.

What about oauth? Jwt tokens? Swagger api docs?

If you've enabled authentication adding the @authenticated decorator will put the endpoint behind OAuth.

Would it be possible and better to build on FastApi?

If someone decides to reimplement the entire Bokeh server functionality on top of FastAPI I'd be very happy but I'd estimate that would take me 1-2 months.