Update cache SPI and resource serialization

[wzy1935]

Closes #67

Updated the cache SPI and added serialization for the Resource class.

[tsegismont]

Thank you @wzy1935 ! I did a first round of comments

[tsegismont]

Thank you @wzy1935 , I've added another batch of comments

Can you also add a test that verifies the behavior of a shared cached? That is, if it has stored a response for a one reverse proxy instance, another proxy instance will not have to contact the backend.

[tsegismont]

Thank you @wzy1935 ! Some more comments

[tsegismont]

Can you please rebase this PR? Thank you

[tsegismont]

Thank you @wzy1935 , another batch of reviews

[tsegismont]

We didn't talk about clearing the map on close, did we? Would it be necessary in your opinion?

[wzy1935]

Personally I also think there's no need, but when I called the vertx.createSharedResource() in ReverseProxy#newCache, there's a closeFuture that I don't know how to deal with it.

Maybe you could check if the following would work? I think I should change to this version:

  // ReverseProxy#newCache
  public Cache newCache(CacheOptions options, Vertx vertx) {
    if (options.getShared()) {
      CloseFuture closeFuture = new CloseFuture();
      return ((VertxInternal) vertx).createSharedResource("__vertx.shared.proxyCache", options.getName(), closeFuture, (cf_) -> {
        Cache cache = new CacheImpl(options);
        return cache;
      });
    }
    return new CacheImpl(options);
  }

[tsegismont]

The close future is not bound to anything, neither Vert.x nor the context. Take a look at how Vert.x creates shared http clients, or shared Vert.x SQL Clients, shared Kafka Producers

[wzy1935]

Is this correct then?

  public Cache newCache(CacheOptions options, Vertx vertx) {
    if (options.getShared()) {
      VertxInternal vx = (VertxInternal) vertx;
      CloseFuture closeFuture = new CloseFuture();
      Cache cache = vx.createSharedResource("__vertx.shared.proxyCache", options.getName(), closeFuture, (cf_) -> {
        return new CacheImpl(options);
      });
      ContextInternal ctx = vx.getContext();
      if (ctx != null) {
        ctx.addCloseHook(closeFuture);
      } else {
        vx.addCloseHook(closeFuture);
      }
      return cache;
    }
    return new CacheImpl(options);
  }

So now I know the callback (the cf_ one) doesn't need to close anything because there's nothing to close for the Cache interface; and for the outside closeFuture, my current understanding is that by calling closeFuture.close() means declaring "giving up the reference holding" of this shared resource and reduce the reference counter (Hook.count) by 1.

Correct me if I'm wrong: the outside closeFuture still should be managed because we want to maintain the reference counter correct, and when the vertx.close() is called, the counter will be cleared to 0 even if newCache being called multiple times (because addCloseHook is registered multiple times as well).