Add Marc21XmlEncoder

[dr0i]

Resolves #527.

Marc21XmlEncoder acts as a wrapper. It makes use of Marc21Encoder, Marc21Decoder and MarcXmlEncoder to ensure a proper MarcXml, especially regarding the leader. Also - in contrast to MarcXmlEncoder - the record id (field 001) is mandatory.

[dr0i]

There may be a better way of implementing this. Probably at least regarding the tests.

To understand the difference between MarcXmlEncoder and Marc21XmlEncoder see e.g. bff54da#diff-9fb05322904ee7e4b0be892e9c4a42db323e95f617277dfd9ee0d7c233a604fcR227, where issue336_createRecordWithTopLevelLeader_Marc21Xml is expected to fail when computed by MarcXmlEncoder but fine when using Marc21XmlEncoder .

Another difference is that Marc21XmlEncoder expects the existence of field 001 (aka record id).

[blackwinter]

I think having both encode-marcxml and encode-marc21xml might be confusing. I would have preferred an option on encode-marcxml (whose default could be flipped with the next major version). But if you feel that it's too complicated to implement, I'm okay with it.

[dr0i]

With fde6ba1 comes the incorporation of the new feature into MarcXmlEncoder. Note, though, that this makes MarcXmlEncoder a singleton (to avoid recursion ad infinitum) and thus, if it comes to threads, a) disables any performance gains ? b) is not thread safe?
Also note the test ensureCorrectMarc21XmlParameterAfterSettingReceiver which throws a NPE when setting the ensureCorrectMarc21Xml after setting the receiver of the pipeline (which cannot happen using flux but can happen when using the Java-API).
@blackwinter you may have a better idea re implementation

[blackwinter]

Not sure if this is so much better, but it may be helpful to separate the concerns more clearly. See c1f8f98 (with some additional fixes/cleanup).

[dr0i]

Thx - your changes are very good, i.a. the encoder is threadable again 👍

[blackwinter]

Superseded by #538 and #539.