ingest/loadtest: add embedding for default apply-load config

[cjonas9]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've reviewed the changes in this PR and if I consider them worthwhile for being mentioned on release notes then I have updated the relevant CHANGELOG.md within the component folder structure. For example, if I changed horizon, then I updated (services/horizon/CHANGELOG.md. I add a new line item describing the change and reference to this PR. If I don't update a CHANGELOG, I acknowledge this PR's change may not be mentioned in future release notes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

• Adds //go:embed directive for the default config, now shipped with the package
• Adds an accessor DefaultConfig() to the package and makes supplying one's own config optional
  • if a config isn't supplied, this config is used
• Options{} now takes the config as []byte rather than as a path to the config

Why

In Horizon and RPC, this config is sufficient for most use cases. For use cases outside of this, it's acceptable to make a custom, purpose-built config that documents itself/the reasons the default was insufficient. To reduce the surface-area of the call, configs can be supplied as []byte so the caller can use the default config directly (as opposed to having to access the embedding and then write it somewhere to get a configPath).

This is being done now (prior to migrating the Horizon/RPC loadtests to use the new SDK loadtest tooling) as a minor change to avoid having follow-up PRs across each of SDK, RPC, and Horizon.

Known limitations

N/A

[Copilot]

Pull request overview

This PR updates ingest/loadtest’s apply-load runner to ship a built-in default stellar-core apply-load config (via go:embed) and changes the API so callers can optionally supply their own config as raw bytes rather than a filesystem path.

Changes:

• Add and embed a default apply-load config file (configs/default-apply-load.cfg) and expose it via DefaultConfig().
• Update Options to accept Config []byte (optional) instead of ConfigPath string, defaulting to the embedded config when nil.
• Refactor config parsing/tests to operate on in-memory config bytes instead of reading from disk.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.

File	Description
ingest/loadtest/configs/default-apply-load.cfg	Adds the package-shipped default apply-load configuration that will be embedded.
ingest/loadtest/apply_load.go	Embeds/exposes the default config, changes Options API to accept config bytes, and writes config bytes into the workdir before invoking stellar-core.
ingest/loadtest/apply_load_test.go	Updates config parsing tests to use DefaultConfig() / in-memory config bytes rather than a testdata file.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tamirms]

I think you can return defaultConfig without creating a copy because I don't think the slice is modified