Add mechanism to get blockhash queue length

[CriesofCarrots]

Problem

It can be crucial for clients to know if a particular blockhash has expired. getFeeCalculatorForBlockhash offers one way to test this, but it would also be helpful for clients to be able to estimate how many slots until expiration. getRecentBlockhash returns the slot context of the response, so clients just need the blockhash queue length to track its expiration.

We may also want to be able to change how long a blockhash is valid for, most likely at epoch boundaries.

re: #10054 (comment)

Summary of Changes

• Add getBlockhashLifespan rpc endpoint. Response includes the relevant epoch, on the assumption that any queue-length changes will be valid for the entire epoch.
• Plumb getBlockhashLifespan through client
• Brush up solana fees, and add blockhash-lifespan info to it.
• Also sneak in a few camelCase tags that were missing in cli_output

[mvines]

docs/src/apps/jsonrpc-api.md 💔

[mvines]

Funny thing, I'm currently improving solana ping and this is a thing I could immediately use

[garious]

What about returning the lifespan via get_recent_blockhash_with_commitment()? And better, what about returning a "valid_through_slot_height" instead of a lifespan. That'd save me the trouble of the next question, where do I get the "birth date" of the blockhash with this "lifespan"?

[codecov]

Codecov Report

Merging #10162 into master will increase coverage by 0.0%.
The diff coverage is 40.9%.

@@           Coverage Diff           @@
##           master   #10162   +/-   ##
=======================================
  Coverage    81.3%    81.4%           
=======================================
  Files         283      283           
  Lines       66038    66094   +56     
=======================================
+ Hits        53731    53829   +98     
+ Misses      12307    12265   -42