Drop (useless?) `is_expected.to compile` examples

[jay7x]

Those is_expected.to compile looks useless from my perspective because there are other examples checking for other things in the catalog. So we can see the catalog compilation is failed anyway.

The benefit here is to reduce the unit test suite execution time.

[jay7x]

Below are some unit test benchmarks on my m1-based macbook

Before the change: 9442 examples, 0 failures, 14 pending

• rake spec_standalone: Finished in 11 minutes 10 seconds (files took 4.44 seconds to load)
• rake parallel_spec_standalone: Took 187 seconds (3:07)

After the change: 8182 examples, 0 failures, 14 pending

• rake spec_standalone: Finished in 8 minutes 56 seconds (files took 4.53 seconds to load)
• rake parallel_spec_standalone: Took 168 seconds (2:48)

[duritong]

Afair compile does validate relationships, I don't think other tests do that.

[duritong]

At least in the past compile catched issues that were not visible in other tests.

[duritong]

Yeah this is essentially what we are interested in and what compile gives us: https://rspec-puppet.com/documentation/classes/#test-that-the-catalogue-compiles

It will test that the manifest can be compiled into a catalogue, and that the catalogue has no dependency cycles between resources.

The second part is what the other tests don't give you afair.

[jay7x]

Ah! Right, I didn't thought about relationship.. let's close the PR then