src: feature-flag default logger, start/with_level

[Fishrock123]

Refs: #548

The easier to fix that and related issues.

This doesn't tackle CookiesMiddleware because it's practically necessary, I think?

[vladan]

This won't resolve the issue of duplicate log entries when using nested routes, i.e. when the logging middleware flag is enabled, duplicate log entries will still appear, right?
IMHO this creates more work for the user than #468 in that the feature flag needs to be unset and the user should set up a logging middleware from scratch ... it's likely I'm wrong, just feels a bit too much work, and some overhead of having a feature flag for just the logger.

[yoshuawuyts]

We can probably scope the entire logger submodule behind a feature flag; but this looks reasonable enough to merge. Thanks!

[Fishrock123]

@vladan i bliebe the answer will likely end up being a TypeMap for Middleware. I’ll try to look at your PR and into this more this coming week.

[jbr]

@Fishrock123 how would a typemap work? Middleware are ordered, and also should be able to accommodate more than one instance of a given type

[Fishrock123]

Sorry perhaps not a type map but maybe some kind of typeId registry, where a middleware can optionally choose to say that it should only be one, or specify a needed dependency.

[jbr]

That seems complex. What problem does it solve? Also how could a middleware know if it's the only one of it's type? That imposes a constraint on middleware that limits the utility. Is this so we have a way to downcast from dyn Middleware? We could just have a DynMiddleware struct that captures the typeid and provides a downcast, and then have a Vec<DynMiddleware>

[jbr]

@Fishrock123 for the "only run once" thing, see #662 for a proposal that doesn't require any changes to the middleware implementation and allows an individual middleware to configure it's "run-once" behavior