Must be null related issues

[Kudbettin]

Then it must contain something

• Fixed Then it must contain something where found but empty properties were not passed to the stash. This bug was affecting the listed issues indirectly, as the resources without any tags were not passed to the next step at all.
• Improved Then it must contain something and Then it must not contain something by removing legacy code.

Then it must be null

• This used to be a special case of Then its value condition match the "search regex" regex. This was problematic and not enough as documented by the listed issues.

• Definition of what is considered to be null or not in this step is ambiguous and not documented well enough. (Once this PR is approved, documentation should be updated with the most recent state of the branch as well)

Current decisions is as follows:

• Should it check if there are values within? (e.g. the current stash is not nothing)
  • Yes. For example, if there are no tags defined, the resource might still have an empty tags property. This should be considered as null (Used to be no)
• Should it check for 'null' strings?
  • No. (Used to be yes)
  • This shouldn't be about the string but the value itself
  • nulls in the planfile/main.tf are converted to Nones in python. Having a 'null' is more likely to indicate the value is not null but happened to be named 'null' than otherwise.
• Should it check for None?
  • For sure. This the bread and butter null value
• Should it check for 'None' string
  • No. See the bullet for 'null' strings
• Should it check for '' string
  • Yes, but I don't know why.
  • The old one checks it, so there should be some reason behind it

resource "aws_s3_bucket" "b" {
  bucket = "my-tf-test-bucket"
  tags = {
     SomeTag    = ""
  }
}

• e.g. running the following steps on this resource would not pass:

Given I have resource that supports tags defined
Then it must have tags
And its value must not be null

* Should this stay as it is, or am I right to think it's incorrect to count this as null?

• Should it check for '\x00'?
  • I have no idea what it does, just left it.
  • Probably similar to the bullet above.

Big Decision

• When the step is "must not be null", should all inner values not be null or at least one non-null value is enough to consider the resource not null?
• Could possibly add both options as new names, but it's pretty clutter-y
• decision: condition_must not be null -> Ok if at least one element is not null
  condition must -> Fail if at least one element is not Null (i.e. Ok if all elements are null)
• Is this a good decision?

Addresses #338, #343

[coveralls]

Pull Request Test Coverage Report for Build 1196

• 5 of 26 (19.23%) changed or added relevant lines in 3 files are covered.
• 6 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.006%) to 57.119%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
terraform_compliance/steps/steps.py	1	2	50.0%
terraform_compliance/steps/then/it_must_contain_something.py	0	3	0.0%
terraform_compliance/steps/then/its_value_condition_be_null.py	4	21	19.05%

Files with Coverage Reduction	New Missed Lines	%
terraform_compliance/common/defaults.py	6	85.0%

Totals
Change from base Build 1190:	0.006%
Covered Lines:	1344
Relevant Lines:	2353

---

💛 - Coveralls

[Kudbettin]

Not checking for the string 'null' as it's converted to None automatically

[Kudbettin]

Smells legacy code. Is it even possible to not have values in a resource anymore?

[Kudbettin]

For the error message:
can also put them both at the same time but feels a bit cluttery
e.g. _step_obj.context.name, resource.get('address', 'address could not be resolved')