Use jetty specific websocket API jar

[gregw]

Similarly to #3162, we may need to create our own rebundled websocket -api jar with OSGi headers.

Currently we run in OSGi tests with this hack:

    private static void fixJavaxWebSocketApi(BundleContext bundleContext)
    {
        try
        {
            // this is necessary because the javax.websocket-api jar does not have manifest headers
            // that allow it to use ServiceLoader in osgi, this corrects that defect
            TinyBundle bundle = TinyBundles.bundle();
            bundle.set(Constants.FRAGMENT_HOST, "javax.websocket-api");
            bundle.set(Constants.REQUIRE_CAPABILITY,
                "osgi.serviceloader;filter:=\"(osgi.serviceloader=javax.websocket.ContainerProvider)\";resolution:=optional;cardinality:=multiple, osgi.extender; filter:=\"(osgi.extender=osgi.serviceloader.processor)\"");
            bundle.set(Constants.BUNDLE_SYMBOLICNAME, "javax.websocket.api.fragment");
            InputStream is = bundle.build(TinyBundles.withBnd());
            bundleContext.installBundle("dummyLocation", is);

            Bundle websocketApiBundle = TestOSGiUtil
                .getBundle(bundleContext, "javax.websocket-api");
            assertNotNull(websocketApiBundle);
            websocketApiBundle.update();
            websocketApiBundle.start();
        }
        catch(Exception e)
        {
            throw new RuntimeException(e);
        }
    }

This adds the required OSGi manifest entries, so some tests pass... however we are getting some chicken-vs-egg problems with some tests. More over, it is unreasonable to expect a user application to do the same.

So either we make our own api jar... or wait for the jakarta one (if it will have the right headers? @joakime ???)

[sbordet]

@gregw JakartaEE jars are probably far away in the future, so I would go for our own repackaged jar.