Standardize Memory Cache API: Align delete operation with KV API

[mar-cf]

No description provided.

[danlapid]

@rts-rob did mention that while aligning on api in terms of method names/signature is good we shouldn't align on async vs sync.
If we are able to make the operation sync instead of async we should.
He commented that on Jan 7th in the internal ticket.

[kentonv]

In the past we've discussed wanting this interface to be able to be backed by a colo-wide cache without having to change the calling code, in which case delete() would need to be async.

But per the other thread I'm unsure if we should be adding this method at all.

[rts-rob]

For clarity, we don't prefer or require sync over async, I was just trying to point out that we don't require it to be async to be match KV's API. Either implementation is fine for KV.

[jasnell]

+1 to having this return a promise if we add it at all. Doing so is going to give us the most flexibility with the implementation long term.

[fhanau]

I'm not very familiar with volatile cache/memory cache, but except for acquiring the lock in SharedMemoryCache::Use::delete_() this looks like a mostly synchronous operation here right? Not sure if we should add a span here since we'd expect the operation to complete very quickly; we'd also need to add some internal plumbing to support/document the span.

[github-actions]

The generated output of @cloudflare/workers-types has been changed by this PR. If this is intentional, run bazel build //types && rm -rf types/generated-snapshot && cp -r bazel-bin/types/definitions types/generated-snapshot to update the snapshot. Alternatively, you can download the full generated types:

Full Type Diff