Support any HTTP header and include blob hash

[Tzal3x]

We can modify the Resource struct as follows.

struct Resource has store, drop {
    path: String,
    // NEW: vector of headers.
    headers: vector<HttpHeader>,
    blob_id: u256,
    // NEW: hash of the blob's bytes.
    blob_hash: u256,
}

// NEW: struct for HTTP headers.
struct HttpHeader has store, drop {
    name: String,
    value: String,
}

Developers can then specify a full list of custom HTTP headers; the portal will read this list, and set them in the ~Response~ Resource object.

This list will be specified in ws-config.json like so:

{
  "headers": {
    "/index.html": {
      "Content-Type": "text/html",
      "Content-Encoding": "gzip",
      "Cache-Control": "max-age=3600"
    }
  },
  "routes": [
    {
      "route": "/*",
      "serve": "/index.html",
    }
  ]
}

Further, the blob_hash should contain the hash (sui::hash::sha256) of the contents of the blob.

Before serving the blob from the aggregator, the portal should check that the hash matches. This way, the developer can ensure that a client only receives the content they intended to serve (assuming a trusted portal, and a trusted full node or light client implementation).

[Tzal3x]

📝 A note on why we need blob hashing along with blobId, because one might think "wait a second, doesn't the blobId already contain a hash of the contents? why do we need another one?"

You can think of it as a very structured hash of the blob (which also depends on the encoding of the slivers 👉 source).

Computing the blobId from the blob contents to check if the aggregator is trustworthy is computationally expensive to happen on the client side.

On the other hand, just hashing the contents returned by the aggregator, instead of regenerating the blobId is faster. So we need to add that blob_hash to the site::Resource to accomplish the above.