Add a way to pass std and format-specific parser/generator flags during parser/generation construction #1058
Description
(note: functionality is cross-cutting between databind and jackson-core, but I'll file main issue here)
With Jackson 2.6, it is possible to specify dynamically changeable "standard" parser/generator features (JsonParser.Feature, JsonGenerator.Faeture), by using ObjectReader / ObjectWriter methods.
Jackson 2.7 adds similar functionality to pass format-specific features for other data formats.
But one problem in both cases is that the way overrides are passed only comes after construction of parser / generator instances. This works for most features, but not all, as some constructors (or, parser bootstrappers) must use information they get from factory; and as a result, a subset of features can not be passed dynamically.
While it would be technically possible to rewrite parser, generators to have sort of delayed initialization for features involved, that would lead to more complex state, error-prone checks.
So instead it would seem better to be able to pass feature flags to the constructors.
Aside from explicitly passing flags, a better (not perfect but better) encapsulation could be to use existing IOContext for passing this information.
But even with IOContext, there is the question of how overrides would be passed to JsonFactory and sub-classes. The long and short of it is that this must be done by adding new factory methods for construction. This is unfortunate, but I don't see a way around that.
One remaining question there is how methods should be augmented. One possibility would be to pass two int flag sets; but this seems fragile, and bit confusing in some cases (when passing byte[] or char[] buffers with offsets). It is also non-extensible.
Adding a new simple configuration container interface type is probably a lesser evil -- while we do want to minimize additions, one more interface, implemented by existing context objects (SerializerProvider, DeserializationContext), probably would work quite well. Note that while abstract class would usually be a better choice, here existing inheritance hierachy prevents this approach.