Properly deprecate removed rules

[brokensound77]

There have been several rules which have been deprecated and removed from the repo. Rules should not be deleted, but instead moved to a deprecated folder and tracked in the deprecated_rules.json file.

• bring back deleted rules and place them in deprecated folder
• update deprecated_rules.json file
• exclude deprecated folder from rule_loader functions
• add unit test to check for deleted files which exist in the version.lock
• add unit test to verify maturity
  • no rules with maturity = "deprecated" are located outside of rules/deprecated folder
  • all rules in rules/deprecated folder have maturity = "deprecated"

[rw-access]

I think the separate deprecated/ folder makes sense for a graveyard of rules.
I also like validating maturity = "deprecated" unit tested against that folder. It should be a 1-1 match.

I don't think we should totally skip it from the rule_loader functionality though. We might run into cases where we want to include a deprecated rule in a rules package anyway. I'm not totally sure the best way we'll communicate deprecated in a rules package. There are two ways that come to mind:

1. Since maturity = "deprecated" isn't ever sent to Kibana, we might want Kibana to look for a deprecated: true field. This doesn't exist yet.
2. Include a list of deprecated UUIDs inside the rules package that Kibana will eventually consume. This could be consolidated in the CHANGELOG, like [snapshot] Create minimal detection_rules package package-storage#843 where I'm exploring the idea

I don't know the right answer to communicate "please delete rule UUID xxxxxxx" to Kibana inside of a rules package. @spong do you have any insight to tip towards 1 or 2? Or towards a 3?

[spong]

Nothing special to tip one way or the other, but when thinking about this when originally implementing I was leaning towards option 1. for self-containedness that way any UI that is displaying the rule would know whether or not to show a badge displaying so, or limit user actions if ever necessary (also would follow it along if duplicated/exported). Of course we could do both if having access to just the CHANGELOG would prove useful (not needing to parse all rules).

As for UI, I imagine a deprecated badge within Rule Details (and any deprecation text that may be helpful to let them know why or what to use in place of it), and an informational pop-up on update informing them that N Rules have been deprecated should suffice here?

[brokensound77]

I don't think we should totally skip it from the rule_loader functionality though.

Totally agree - it is already leveraged in version lock this way, so we will leave it in there.

Option 1 works for me and would fit nicely into the existing workflow