test_rpc_slot_updates fails if SlotUpdate::Completed is received after
SlotUpdate::Frozen:
https://github.com/solana-labs/solana/blob/dcfd823ca/rpc-test/tests/rpc.rs#L198-L228
However, SlotUpdate::Completed is sent asynchronous to banking-stage and
replay when shreds are inserted into blockstore. When the leader
generates blocks, replay may freeze the bank before shreds are all
inserted into blockstore; and so SlotUpdate::Completed may be received
_after_ SlotUpdate::Frozen.
The commit removes the ordering check for SlotUpdate::Completed.
#### Summary of Changes
Blockstore::blockstore_directory() function takes a ShredStorageType and returns a path.
As it's a ShredStorageType related function, moving it under ShredStorageType as a
member function is a better fit.
In addition, as we start doing automatic shred compaction type selection under ledger-tool,
it becomes more convenient to reuse the function and const under blockstore_options
namespace instead of blockstore.
#### Summary of Changes
Define PERF_METRIC_OP_NAME_PUT and PERF_METRIC_OP_NAME_WRITE_BATCH
to replace repetitive / hard-coded operation names for report_rocksdb_write_perf.
#### Problem
report_rocksdb_read_perf() always uses the hard-coded operation name "get"
#### Summary of Changes
As we will add a new read operation -- multi_get(), report_rocksdb_read_perf()
needs to have an input parameter for operation name.
* Allow extending upgradeable program data account length
* Add is_writable check
* Fix cargo version
* System program fix, comment, and test
* Switch to u32 for serialized bytes value in ix
* slots_connected check used by ledger-tool should not require a full slot for snapshot slot
* Cleaner Result<Option<>> unwrap/default
* return false if no meta for starting slot
* Add clarifying comments
* Use client certs in QUIC to get peer's stake
* fixes to cert processing
* integrate the code
* clippy
* more cleanup
* sort cargo deps
* test fixes
* info -> debug
Add "(experimental)" and use a neutral badge instead of a green one.
The current iteration of verifiable builds does not come with
particularly strong guarantees - best to avoid giving users
any false sense of security.
It relies on an unaudited third party service independent of the explorer,
and the nature of Cargo's build process means it is hard to make strong
claims about the resulting artifacts.
cargo test --package solana-gossip --release test_push_votes_with_tower
occasionally fails because with --release all votes are generated at
the same wallclock (milliseconds resolution) and so the new ones will
not necessarily override existing entries in the table.
The commit ensures that the new vote is pushed with a wallclock later
than existing entries.