[BLS] Expose signing and verification api that takes as input an already mapped-to-point msg

[kchalkias]

This will enable caching when the same msg is used for signing and verification (or when we fall back to single sig verification in consensus). See this tweet: https://twitter.com/kostascrypto/status/1656809806198640640?s=20

[benr-ml]

It's not a simple change, so let's first analyze the potential performance improvement (e.g., using flamegraph of batch_verify with 10/100/1000 signatures).

[kchalkias]

@benr-ml map-to-point is ~70 microsec (pretty much half the signing cost or ~6.5% faster aggregated sig verification - assuming you were a signer and you had it in LRU). I guess adding the LRU is easy, and the complexity is on utilizing the BLST api to input a map2point directly during verification, right?

[benr-ml]

Thanks, let's also check this with batch_verify since that's what we're hoping to optimize (maybe it's better...).
As for the LRU, probably not too difficult, but yeah, the changes to BLST will be the more tricky part, we'd need to break the rust interfaces/use the C++ ones directly.

[jonas-lj]

I thought about breaking the interfaces anyway to utilise pre computation on the pairing (see #507). We should do some experiments first though.

[kchalkias]

@jonas-lj and @benr-ml yes we need some data from testnet and mainnet, as said in the recent past, we record all ideas in GH (not to forget them) and then see what makes sense based on data we get every week.