Ledger enclave support for router and store

[NotGyro]

• Adds ledger_store_init(), frontend_accept(), and ledger_store_connect() to the Fog ledger enclave API for general use with a fog ledger router/store system
• Adds check_key_image_store(), decrypt_and_seal_query(), create_multi_key_image_store_query_data(), and collate_shard_query_responses() to the Fog ledger enclave API, which are currently specific to key-image store queries
• Implements all of the above new API methods, including stub methods for testing.
• New EnclaveCall variants for the above methods.

Depends on #2889

Motivation

As part of the ongoing project to improve Fog's scalability and stability, we're working on implementing a system that divides Fog ledger servers into a router (which routes requests from the client to a number of ledger store backends) and many stores (which actually hold relevant ledger data). Currently, only key image look-ups are supported.

Future Work

• Generalize such that the ledger router/store system can be used for other ledger queries, not just key image queries (for example, merkele proofs).

[awygle]

Current dependencies on/for this PR:

• feature/fog-ledger-router
  • PR Pull in protobuf changes from milliec/ledger-router-dev #2889
    • PR Ledger enclave support for router and store #2896 👈
      • PR URIs for Fog Ledger Router #2897
        • PR Protobuf conversion functions for Fog Ledger Router #2891
          • PR Key Image Router Service #2898
            • PR Oblivious collation of key image store responses #2913
              • PR Fog Ledger Router Admin service #2920
                • PR Key Image Router Server + Binary #2921

This comment was auto-generated by Graphite.

[awygle]

I approve this but I think we might want to wait for James or Nick.

[nick-mobilecoin]

❓ I didn't quickly find it, will this be converted to a Vec<> like the view collation?

[awygle]

So the difference between us and View is that View passes the whole MultiViewStoreQueryResponse to the enclave while we just pass the encrypted message and the responder ID. I don't see a huge advantage either way, to be honest.

[nick-mobilecoin]

💭 I don't think it should be done in this PR, and I need to better understand the 2 Deserialize traits, https://serde.rs/lifetimes.html#trait-bounds
But something about the inbuf and outbuf repeated everywhere seemed to gnaw at me
I wonder if something like this provides any benefit?

impl LedgerSgxEnclave {
    fn call_wrapper<T>(&self, call: &EnclaveCall) -> Result<T>
        where
            T: DeserializeOwned,
    {
        let inbuf = mc_util_serial::serialize(call)?;
        let outbuf = self.enclave_call(&inbuf)?;
        mc_util_serial::deserialize(&outbuf[..])?
    }
}

/// Proxy API for talking to the corresponding implementation inside the
/// enclave.
impl LedgerEnclave for LedgerSgxEnclave {
    fn enclave_init(&self, self_id: &ResponderId, desired_capacity: u64) -> Result<()> {
        self.call_wrapper(&EnclaveCall::EnclaveInit(
            self_id.clone(),
            desired_capacity,
        ))?
    }

[jcape]

Some nits, but generally LGTM