Prevent HTTP Requests When No VCR Cassette Is Loaded

### Problem

We appear to allow HTTP requests to be made by the test suite when VCR does not have any cassettes loaded:  https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/34e3aa33adfd643f98d6ce3277a8fc449393d893/spec/support/vcr.rb#L6

This makes it too easy to accidentally write a test that makes real HTTP requests every time it runs.

Here's one example of how this can happen:  https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3209#note_570376985

In short, if we use `let_it_be` with a factory that makes HTTP requests, then this will bypass VCR and always make real HTTP requests.  This makes it very easy to accidentally slip real HTTP requests into the test suite.  And there may be other ways this can happen.

Here's another place we're we've discussed this being an issue:  https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2565#note_558470717

I [made an MR to experiment with changing this](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3217) within the scope of ~"Stuff that should Just Work".  In doing so, I discovered that we have a few tests that seem to make HTTP requests every test run.  Here is one such instance caused by using `let_it_be`: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3217/diffs#808512b32fff3a0a4332697e4a370a042f91ae1a_748_748

One easy way to verify that the test suite is bypassing VCR and attempting to make real HTTP requests is to disconnect from the network (disable your wifi, unplug your ethernet cable, etc) and then run the following spec: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/34e3aa33adfd643f98d6ce3277a8fc449393d893/spec/controllers/subscriptions_controller_spec.rb#L747

It will generate errors like the following:

```
Faraday::ConnectionFailed:
  Failed to open TCP connection to rest.apisandbox.zuora.com:443 (getaddrinfo: nodename nor servname provided, or not known)
```

In contrast, it passes locally if the network is enabled.

#### Notes

Here are just a few further notes from code spelunking this:

This appears to be the magic that lets us use `:vcr` in our specs to get VCR to automatically find and load cassettes:  https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/98e48709688a0478ec245b0e2155b545c5986940/spec/support/vcr.rb#L9

That function is here in VCR:  https://github.com/vcr/vcr/blob/5c0ded824dd8b1f9d50ab5d48a53be065b94ece8/lib/vcr/configuration.rb#L420

Which uses RSpec’s `config.before(:each)` to load cassettes:  https://github.com/vcr/vcr/blob/5c0ded824dd8b1f9d50ab5d48a53be065b94ece8/lib/vcr/test_frameworks/rspec.rb#L35

Which seems to run after `before(:all)` (see the Order section):  https://rubydoc.info/github/rspec/rspec-core/RSpec/Core/Hooks

`let_it_be` seems to be equivalent to using `before_all`:  https://test-prof.evilmartians.io/#/recipes/let_it_be?id=modifiers

Which I think ultimately uses `before(:all)` under the hood: https://github.com/test-prof/test-prof/blob/7d8effe48fa65418b0ee9a77d932d86fed240b51/lib/test_prof/recipes/rspec/before_all.rb

I’m not sure I’m tracing through all that 100% correctly, but it’s in the ballpark.

### Proposal

Let's [change this line](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/34e3aa33adfd643f98d6ce3277a8fc449393d893/spec/support/vcr.rb#L6) to `c.allow_http_connections_when_no_cassette = false` so that HTTP requests are always denied in the test suite unless we specifically allow them for a particular test.

Unfortunately, I haven't found a clear way to disable VCR and allow http requests for specific tests, which may be why we currently have `allow_http_connections_when_no_cassette` set to `true`.

But perhaps something like the following may work:

```ruby
WebMock.allow_net_connect!
VCR.turn_off!
```

Followed by the following to re-enable VCR and prevent HTTP connections:

```ruby
WebMock.disable_net_connect!
VCR.turn_on!
```

Or maybe tests that require HTTP connections should be moved to the QA test suite?

Maybe there are other ways to solve this?

### Result

Our test suite will stop leaking HTTP requests.

It will be harder to accidentally make HTTP requests from the test suite.  VCR / WebMock will always block the requests unless clearly disabled for a particular spec.

### Next steps (if any)

### How will we measure success?

Story points: 5.0