Drop the Config builtin

[buffalojoec]

Problem

The Config program has been migrated to an on-chain BPF program. It's time to remove it from the monorepo.

Summary of Changes

Commit-by-commit, unwind the Config program's API being used around the validator, then finally drop the program entirely.

[mergify]

The Firedancer team maintains a line-for-line reimplementation of the
native programs, and until native programs are moved to BPF, those
implementations must exactly match their Agave counterparts.
If this PR represents a change to a native program implementation (not
tests), please include a reviewer from the Firedancer team. And please
keep refactors to a minimum.

[buffalojoec]

@tao-stones I've requested your review here, since the eviction of the Config program modifies the builtin cost tracker setup.

The contributor warnings around the builtin tracker list explicitly mention how to treat existing builtins that are going to be migrated and those that are not going to be migrated. However, it does not say anything about builtins that have been migrated on all three clusters.

Based on our previous conversations in SIMD 0170 and the codebase within solana-builtins-default-costs, removing a builtin from this list that is already 100% migrated is appropriate.

Let me know if you feel otherwise!

[buffalojoec]

@topointon-jump FYI this PR touches the stake program, but it does not practically change anything about it. It merely updates it to use the Config program's client, rather than the builtin library from this repository. Same interface.

[tao-stones]

Look good from builtin cost perspective. config will no longer be builtin, its default cost will be 200K CUs.

[apfitzge]

Looks correct to me, but have a general question about builtin migrations that is related.

I see that we use core_bpf_programs() to add the bpf accounts for our program-test and test-validator...how does this work for a new cluster? are the accounts added in genesis or something?

[buffalojoec]

Looks correct to me, but have a general question about builtin migrations that is related.

I see that we use core_bpf_programs() to add the bpf accounts for our program-test and test-validator...how does this work for a new cluster? are the accounts added in genesis or something?

Yes, exactly! Here:

agave/scripts/run.sh

Lines 74 to 77 in f56845e

	./fetch-core-bpf.sh
	if [[ -r core-bpf-genesis-args.sh ]]; then
	CORE_BPF_GENESIS_ARGS=$(cat core-bpf-genesis-args.sh)
	fi

https://github.com/anza-xyz/agave/blob/master/fetch-core-bpf.sh

[joncinque]

Looks great to me! Just a couple of small questions

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 94.23077% with 3 lines in your changes missing coverage. Please review.

Project coverage is 83.3%. Comparing base (0a0cce2) to head (223260d).
Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master    #5331     +/-   ##
=========================================
- Coverage    83.3%    83.3%   -0.1%     
=========================================
  Files         828      824      -4     
  Lines      373649   372824    -825     
=========================================
- Hits       311592   310761    -831     
- Misses      62057    62063      +6     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[joncinque]

Looks good to me!

[buffalojoec]

The node has hummed over the epoch rollover and everything seems good. CI passing, comments resolved. Ready to merge.

@tao-stones I re-requested you for the Fees codeowner. Thanks!

[tao-stones]

vouch for fee