Bump core to stable v21.3.0

[leighmcculloch]

The selection of CI checks that are failing seem to suggest that the local mode of running QuickStart is broken in this PR. 🤔

[leighmcculloch]

There are messages in the logs saying:

supervisor: 2024-08-20 01:32:37,729 INFO exited: stellar-core (terminated by SIGABRT (core dumped); not expected)

[marta-lokhova]

@leighmcculloch looks like tests are now passing post-v21.3.1 bump. But there's an issue building core related to stellar-xdr. Could this be related to the fact that v21.3.1 bumped its version of stellar-xdr?

fatal: Cannot fetch both refs/heads/HEAD and HEAD to refs/remotes/origin/HEAD
#15 644.4 error: failed to load source for dependency `stellar-xdr`
#15 644.4 
#15 644.4 Caused by:
#15 644.4   Unable to update https://github.com/stellar/rs-stellar-xdr?rev=ae805d0f8c28ca86327a834eea9ce7d29b0a63bb#ae805d0f
#15 644.4 
#15 644.4 Caused by:
#15 644.4   failed to clone into: /root/.cargo/git/db/rs-stellar-xdr-e36413b8b995c711
#15 644.4 
#15 644.4 Caused by:
#15 644.4   process didn't exit successfully: `git fetch --tags --force --update-head-ok 'https://github.com/stellar/rs-stellar-xdr' '+refs/heads/*:refs/remotes/origin/*' '+HEAD:refs/remotes/origin/HEAD'` (exit status: 128)
#15 644.5 make[3]: *** [Makefile:4562: ../target/release/librust_stellar_core.a] Error 101
#15 644.5 make[3]: *** Waiting for unfinished jobs....

[leighmcculloch]

@marta-lokhova Very strange error. I'm not sure why that would have happened specifically. Note that the error happened as part of running stellar-core's build process, so it failed independent of anything quickstart related. Other builds of stellar-core in the same workflow completed okay, so the issue is hopefully only intermittent.

I suggest we wait till the workflow finishes, then rerun just the failed jobs to see if it passes.

---

Separately to the failure, it looks like stellar-core 21.3.1 was released using an unreleased version of rs-stellar-xdr that contains changes to the XDR for protocol v22 from CAPs that haven't been accepted yet: https://github.com/stellar/stellar-core/blob/v21.3.1/Cargo.lock#L1164-L1174

I assume this has no material impact, but it's somewhat odd to see stellar-core report on its version command that it is using a version of XDR that has changes from CAPs that aren't yet accepted or released and therefore not guaranteed to be stable.

[SirTyson]

CAPs

Some context on these XDR changes. While the BinaryFuseFilter will become part of the ledger hash in protocol 23 as the CAP describes, it also has non-concensus related use cases in 21.3. In particular, we use this filter (and it's XDR) for BucketListDB filters. The XDR spec is the same as what will later be used in p23, but the changes included in this release are internal XDR changes only visible to core (until the CAP is officially passed). Because these are currently internal core-only types, we just patched the env XDR crate at the core level instead of going through an official rs-stellar-xdr release.

[leighmcculloch]

@SirTyson I noticed that. I wasn't specific, but intending to refer to the CAP-58 changes that alter the TransactionEnvelope sub-structures.

I don't think any action is required. Given it's unlikely this case and subsequent cases that might be similar to this would result in a material impact, I don't think it'd be worth significant process to try and prevent this, unless there's a low overhead fix. I understand from talking to @graydon that the use of next has a pretty high overhead and that might be why CAP-58 is already available here.