grep_more_ioc improvements

[aberges-SLAC]

Description

Fixed some bugs in grep_more_ioc and added some QOL on the search sub-parsers. I'm probably the only person using this tool, but it makes life livable in las given the sheer number of IOCs.

Motivation and Context

Fixes #213 and #192 and improves functionality for piping output into other commands/scripts.

How Has This Been Tested?

I have ran ../engineering_tools/grep_more_ioc to use the changes in my fork and can successfully print all IOCs in all hutches, demonstrating #213 has fixed the issue I was seeing before when Alias procmngr keys included forbidden characters and digits that weren't being escaped correctly before reading the JSON.

I have also demonstrated that the new search subparser arguments work as expected:

Where Has This Been Documented?

This PR.
It is important to add that I have redefined what the -o optional flag for search does:

Previously, -o was --only_search, meaning skip printing the dataframe for when you only care about the child ioc search results.

We now have the following options:

    search.add_argument('-s', '--only_search', action='store_true',
                        default=False,
                        help="Don't print the dataframe, just search results.")
    search.add_argument('-o', '--only_results', action='store_true',
                        default=False,
                        help="Only print the results of the regex match. Like"
                        " 'grep -o'.")
    search.add_argument('-n', '--no_color', action='store_true',
                        default=False,
                        help="Don't wrap the search results with a color")

So if you have any scripts built on the output of grep_more_ioc <patt> <hutch> search -o <regex> you need to update it to grep_more_ioc <patt> <hutch> search -s <regex>

[tangkong]

The regex monster grows! I know I've expressed my distaste for regex in the past, so I won't belabor it much here. It is becoming increasingly difficult to read and understand. Maybe the parsing functions here could get some tests some day soon.

[tangkong]

As it stands, this could get a bunch of None values. Are we ok with that getting to the final output? Or do we want to filter that out?

[aberges-SLAC]

I don't mind getting a bunch of None values. The dataframe print/manipulation handles that for the most part. Sometimes the negative space is important for how I am perusing the IOC info

[ZLLentz]

Maybe also importantly, this may print the json error text a bunch of times in a row!
But that could be a feature too.

[aberges-SLAC]

I consider that a feature — in fact it's exactly what I needed to figure out why certain IOCs in RIX were breaking this tool in the first place and realized the problem with my JSONification.

Bethesda would be proud

[aberges-SLAC]

The regex monster grows! I know I've expressed my distaste for regex in the past, so I won't belabor it much here. It is becoming increasingly difficult to read and understand. Maybe the parsing functions here could get some tests some day soon.

One day I'll burn for my sins — but not today!

Tried to at least make the regex consistent — find a procmgr key then json-ify it. Then look for unquoted chars near a procmgr key and quote it too.

Maybe I've just gotten Stockholm's syndrome with regex and Perlre by now 🤷

[ZLLentz]

Seems reasonable to me
I also fear the regex monster

[tangkong]

I think this looks good otherwise. I yearn for tests in this repo as a whole but that's not on you