Add Enums + Remove incomplete currency constants

[Code0x58]

Changes:

• add enums as a move towards typing - includes testing to avoid drift from constants
• use constants + enums in message.py - hopefully an improvement for non-FIX-wizards
• remove incomplete currency constants. I think they may be better taken as arbitrary (byte) strings for now. Strictly this is a breaking/major change, if taken as such (for the next release version number) then it would be good to remove constants.TAG_IOIQlTYIND as well

[da4089]

Thank you for this work!

My plan here was to generate the enums from the FixRepository XML files. That would give 100% coverage, avoid spelling errors, etc, etc. The complication is that some enums/tags have been deprecated in 5.0, and I'd like to have them available. So ... maybe the process could generate an intermediate record from each of the 4.x and 5.x XML specs, and then emit the Python code from there?

I'll have a closer look, but at first glance your general pattern looks good, and I think it'd be a great base for the generated code.

Thoughts?

[da4089]

I've pushed a tool to master that will generate a file not unlike your enums.py from the FIX 5.0sp2 XML spec. As mentioned above though, this spec is missing a bunch of stuff that's been deprecated (from 4.x, mostly) that I'd like to integrate.

[da4089]

@Code0x58 did you have any thoughts on my comments above?

[jvirtanen]

@da4089 It might make sense to take a look at FIX Orchestra as well. The reason is that the latest version of the protocol, FIX Latest, is only available in the FIX Orchestra format. (FIX Latest is essentially FIX 5.0 SP2 plus all the extension packs after it, updated regularly.) Therefore you'll likely end up integrating with it in any case.

In addition to FIX Latest, FIX 4.2 and FIX 4.4 are available in the FIX Orchestra format. I'm still using FIX Repository for those in Philadelphia, but I did verify that using FIX Orchestra for those results in identical output.

You can find the actual specifications here on GitHub.

[da4089]

@jvirtanen I think that's a decent idea. I'd thought that Orchestra basically imported Repository and added some behavioural specs, but having just had a look at it now, it does look a bit different. I'll have to have a more detailed look, but in principle, I'd rather not be adopting a "dead" standard.

[da4089]

@Code0x58 I'd like to close this out using code automatically generated from the Orchestra specs, but which basically matches the style of what you've done here. Are you able to work with me on this PR to achieve that?