Major refactor: flatten code and object structures

[sempervictus]

Major refactor: flatten code and object structures

After converting Field from an enum to a Struct and implementing various generic mechanisms for common functionality, we are seeing legacy code and object structures cluttering and breaking efforts respectively. The MshSegment does not behave like a generic one in terms of structure or implementation, and being "in the line of fire" whenever segments are used to be parsed out through a match statement makes it very cumbersome, sometimes unworkable due to borrow checks on the string references.

Remove the Segment enum and convert GenericSegment struct to be the new Segment struct - possible because Separators live in the Message structure permitting on-demand re-parse of a Segment struct into any other named segment type such as MshSegment. This is how the msh() implementation now works for Message - finding the relevant Segment and returning a parsed MshSegment from it and the Message Separators already stored.

This permits query() and Index<&str> mechanisms to search for all types of segments and fields, using syntax a la MSH.F3 for which a test-case has been added to the feature-gated test.

Now that the object structures and interfaces are generic, simple, and common - the code structure itself has been reorganized per wokket#25 into a flat set of files within src/.

Testing:

• Updated test object derivations to remove destructuring of enums.
• Added check to string-index for MSH fields.
• All tests passing with index_string feature enabled and without

[sempervictus]

@wokket - ops request: due to the addition of features in this PR, could you please enable testing with all features for the CI so we get coverage for test and bench in otherwise obscured parts of the code?

[wokket]

@wokket - ops request: due to the addition of features in this PR, could you please enable testing with all features for the CI so we get coverage for test and bench in otherwise obscured parts of the code?

CI is in .github/workflows/ci.yml so you should be able to tweak that and get it working in your repo, and it becomes part of the PR.

I'm away from the computer this morning but will have a closer look at this this afternoon.

[sempervictus]

My tinfoil-hat-wearing security mindset leads me to think that having anyone who submits a PR run arbitrary commands on something attached to someone else's repo might be dangerous :). Meh, but what do i know?

grep -ri rageltman metasploit-framework/modules/payloads/|wc -l
40

Thanks for the tip - CI is now testing and running bench with the feature enabled.

[sempervictus]

I think GH is confused