troubleshoot the limits validation timing during start with local network

[sreuland]

the 'limits' config file path validation when' local' network was referring to PROTOCOL_VERSION before start had a chance to fully qualify it when not explicitly set from env or param, i.e. it will then set PROTOCOL_VERSION based on current core runtime default version reported after process start.

resolves e2e test failures on stellar-rpc - https://github.com/stellar/stellar-rpc/actions/runs/12363207197/job/34504081784

[sreuland]

this appears to be running too soon since it references PROTOCOL_VERSION, as start has not finished conditionally setting PROTOCOL_VERSION if it's not set and local network, in that case PROTOCOL_VERSION is set later after core has been started dynamically to the default version that the core runtime reports in upgrade_local

[leighmcculloch]

I don't think we should go ahead with this fix, at least based on what I know so far, but please let me know if I'm missing something.

Why: The PROTOCOL_VERSION is never empty anymore. We always set it to a value, and that value is PROTOCOL_VERSION_DEFAULT now.

There are a few lines which handle if the PROTOCOL_VERSION is empty, but we should probably remove them and instead introduce a check right at the beginning that hard errors if both PROTOCOL_VERSION_DEFAULT and PROTOCOL_VERSION are empty.

Asking core what its max supported version is unreliable as a way to know which protocol version is supported by the image as a whole. This is because core can support a version ahead of all the other software and it can take time to upgrade.

We no longer rely on auto-determining the version because otherwise those images would break every time we go through a protocol release.

[leighmcculloch]

@sreuland I suggest we do this:

• Require PROTOCOL_VERSION_DEFAULT #655

[sreuland]

thanks @leighmcculloch for explanation on the current protocol version strategy that quickstart employs, closing this as obsolete.