Start the chef-zero server on demand

[tas50]

Fixes chefspec#1017

Problem

Requiring chefspec pulls in ServerRunner, which pulls in ZeroServer, which registers:

RSpec.configure do |config|
  config.before(:suite) { ChefSpec::ZeroServer.setup! }
  config.after(:each) { ChefSpec::ZeroServer.reset! }

A chef-zero server therefore starts for every suite, including suites that only ever use the SoloRunner. That reserves one port from server_runner_port (default 8889..8899) for the whole run, so no more than 11 suites can run concurrently before they fail to find a free port. It also runs a data reset after every single example.

Measured on a suite that only uses platform and SoloRunner, before the change:

PID 98098 sees open ports: [8889, 8890]
PID 98100 sees open ports: [8889, 8890]

Fix

Start the server the first time something actually needs it, from upload_cookbooks!, load_data and the server accessor, and skip the per example reset while it is not running.

This is the third option the reporter suggested. It is not a breaking change: ServerRunner behavior is unchanged, and code that starts the server explicitly, as examples/server/spec/exotic_port_spec.rb does, still works.

Testing

Adds a no_server acceptance example asserting no chef-zero server is running for a SoloRunner only suite.

• With the fix: 2 examples, 0 failures, and no ports bound
• With the fix reverted: 2 examples, 1 failure
• server acceptance example (all ServerRunner): 17 examples, 0 failures
• Unit suite: 197 examples, 0 failures

[tas50]

CI on this PR is red for an unrelated reason: main's bundle cannot be installed on Linux, which breaks every job before any test runs. That is fixed separately in #56, which is green across Ruby 3.1 to 3.4. This PR should go green once #56 lands and this branch is rebased.

Locally, against a working bundle, this branch passes rake unit and the acceptance examples.