4:x: Filter ordering should honor feature weight

[tomas-langer]

This is the expected ordering of features:

Feature	Weight
Context	1100
Access Log	1000
Tracing	900
CORS	950
Security	800
Routing (all handlers)	100
OpenAPI	90
Observe	80

Anything configured in routing should honor this ordering - i.e. if a filter is registered in AccessLog feature, it should be called before any filter registered in routing.

Right now it seems that all routing filters are called first, and then filters from features (in correct order based on their weight).

This must be fixed, and a test created to validate that this ordering is honored.

[tomas-langer]

Current behavior: As long as you use an HttpFeature to configure a filter, it will honor its weight If you register filter using routing directly, it will be considered default weight, ordered by insertion Behavior of filters added directly from ServerFeature.setup :

• it will be after filters in routing
• it will be before filters from HttpFeatures with less than default weight
• it will be in the order of the server features (depending on whether the feature is added by hand or discovered automatically)

[tomas-langer]

Behavior before fix (where the filter comes from (weight)):

http-feature(999)
routing-first(N/A)
routing-second(N/A)
server-feature(99)
server-feature(1000)
http-feature(98)

Desired behavior after fix:

server-feature(1000)
http-feature(999)
routing-first(N/A)
routing-second(N/A)
server-feature(99)
http-feature(98)

[RickyFrost]

Can we have a way to specify filter weight if using the following bootstrap?

final webServer = previouslyCreatedAndPopulatedServerBuilder.routing(
        HttpRouting.builder().addFilter(new MyFilter())
                // register other routings here...
                .build()
    ).build();

Otherwise, the only way to do it will be to create a "for no other reason" ServerFeature... (for which there isn't even a guide today).