Proposal: Change APIs to support sync multihashers

[Gozala]

I find strictly async interface for MultihashHasher to be problematic as it induces asynchrony even when that is impractical (from performance and API point of view). My specific use case is related to HAMT implementation which uses murmur3 that is non cryptographic hash and really doesn't need to be async, not to mention that actual implementation is sync. More generally, I think it would be reasonable to have an API that:

1. Provides general async API that can be used across implementations
2. Allows hasher user to conditionally avoid await at expense of increased code complexity.
3. Allows certain functions to demand Sync API as needed.

I propose to amend current interface definition as follows:

export interface MultihashHasher {
  /**
   * Takes binary `input` and returns it (multi) hash digest.
   * @param {Uint8Array} input
   */
  digest(input: Uint8Array): MultihashDigest|Promise<MultihashDigest>

  /**
   * Name of the multihash
   */
   name: string

  /**
   * Code of the multihash
   */
  code: number
}

export interface SyncMultihashHasher extends MultihashHasher {
   digest(input: Uint8Array): MultihashDigest
}

This way

1. All existing MultihashHasher implementations are compatible as MultihashHasher just widened return type of digest function.
2. All users of MultihashHasher can continue using await or choose to do so if return type is a promise.
3. Some implementations could switch to SyncMultihashHasher while retaining compatibility with all the existing code.

[rvagg]

yep, I agree and have thought about this previously - I've started defining and using a MaybePromise<T> elsewhere for the same reason and it's quite usable - by default you can await everything but where perf matters you can check what you're getting; and the SyncMultihashHasher would give an extra option for feature detection, so +1 to that.