Reduce Puma and Pulp worker counts for development tuning

[pablomh]

Why are you introducing these changes?

Puma and Pulp worker/process counts are derived from live hardware facts (processor count, memory) rather than from the selected --tuning profile:

• foreman::foreman_service_puma_workers defaults to floor(min(100, cores*1.5, mem_gb-1.5))
• foreman_proxy_content::pulpcore_worker_count defaults to min(8, cores)
• pulpcore::content_service_worker_count defaults to 2*min(8,cores)+1
• pulpcore::api_service_worker_count defaults to min(4,cores)+1

This means --tuning development's minimal hardware floor (1 CPU core / 6 GB, see hooks/pre_commit/13-tuning.rb) doesn't actually cap these: any development box above that floor (e.g. a forklift VM with a few cores and more RAM) scales them up the same as default/medium would, and can OOM when Pulp syncs several repositories concurrently.

config/foreman.hiera/tuning/sizes/development.yaml didn't exist before this change, so development silently fell back to tuning/common.yaml with no profile-specific override, unlike medium/large/extra-large/extra-extra-large, which each have one.

Ports theforeman/foremanctl#925 (which fixed the equivalent problem in the container-based installer) to the RPM/Puppet installer.

What are the changes?

• Add config/foreman.hiera/tuning/sizes/development.yaml, pinning the four worker counts above to 2, the same hiera-override mechanism already used by the other tuning sizes.
• Add spec/tuning_spec.rb asserting those values, mirroring foremanctl's own tests/unit/tuning_test.py.

Fixes #39882

Test plan

• CI green
• rspec spec/tuning_spec.rb passes
• rubocop clean on the new spec

🤖 Generated with Claude Code

[ekohl]

This isn't going to work: these parameters are read by Kafo and stored in the answer file. You can see the answers take precedence over the tuning:

foreman-installer/config/foreman-hiera.yaml

Lines 13 to 22 in 05222e7

	- name: "Kafo Answers"
	path: "%{facts.kafo.scenario.answer_file}"
	- name: "Built in"
	paths:
	- "scenario/%{facts.kafo.scenario.id}/family/%{facts.os.family}-%{facts.os.release.major}.yaml"
	- "scenario/%{facts.kafo.scenario.id}.yaml"
	- "family/%{facts.os.family}-%{facts.os.release.major}.yaml"
	- "family/%{facts.os.family}.yaml"
	- "security.yaml"
	- "tuning/sizes/%{facts.kafo.scenario.custom.tuning}.yaml"

Ideally we'd have a tuning test that takes every file in config/foreman.hiera/tuning/sizes and verifies that for each entry the class isn't in the answer files so you'd know what is invalid.