feat: fast exact name search by default

[lidel]

tldr

This PR changes the default behavior of the name filter

from case-insensitive, partial match
to much faster case-sensitive, exact (full) match

and adds match parameter that enables opt-in into alternative strategy when performance is not an object:

PREVIEW: https://ipfs.github.io/pinning-services-api-spec/#specUrl=https://raw.githubusercontent.com/ipfs/pinning-services-api-spec/fix/default-to-fast-name-match/ipfs-pinning-service.yaml

Rationale for this change

• Case-insensitive partial "Fuzzy" search (ipartial) makes a bad default. (performance-wise)
  Database indexes and b-trees do not solve the performance fully.
  Exact match is always faster and less expensive.

• Fuzzy search may produce bugs
  This PR introduces match query parameter, so developers who need fuzzy search can still opt-in into slower, but more flexible text matching strategy by passing match parameter.

• We are moving away from slow defaults in IPFS ecosystem. Better to do this now, than later.

  • A good example of tyranny of small decisions is ipfs pin ls, which is abysmally slow when one has >1k pins. Nearly all pins in real life are recursive, and ipfs pin ls --type=recursive executes instantly, but is rarely used due to not being the default.
  • Future ipfs pin remote and ipfs pin local APIs will be inspired by this spec and will have name attribute, however we don't want to re-introduce bad choices into IPFS ecosystem. The default should be the fastest option available, and in this case it is the exact name match.

Implementation notes and migration plan

• This change does not change the wire format and does not impact ongoing MVP integration in go-ipfs and ipfs-webui (Epic: Pinning service integration ipfs-gui#91, Add support for remote Pinning Services kubo#7559), but we want to include it in this spec to ensure MVP does the right thing.

• Existing Pinning Services already implement the more difficult fuzzy ipartial strategy. Adding support for match filter and implementing much simpler exact strategy should be a small task, but will save everyone headache in the long run.

---

@aschmahmann @jacobheun @petar @gammazero @obo20 @andrew @GregTheGreek @priom @jsign @sanderpick @andrewxhill @ipfs/wg-pinning-services

[aschmahmann]

I agree, this seems much more sensible from an ecosystem perspective.

[aschmahmann]

🚲 + 🏚️ :
"fuzzy" I like that it's short, but not so happy that it's not quite precise in what it does. I'm fine with fuzzy, but putting out the call for better names before we decide we're just going with this one.

[lidel]

I am totally fine with renaming fuzzy to something better.
Food for thought: partial, relaxed, inexact, loose

[jessicaschilling]

+1 for partial unless you specifically need to indicate it's case-insensitive too (if the latter, would suggest something like full-sensitive and partial-insensitive but that gets a little too bikesheddy, probably)

[jacobheun]

+1 for partial

[lidel]

Renamed to partial in 91299cc (#66) and added match=exact|iexact|partial|ipartial in
f96383a to fuel discussion

We need to figure out if thats enough, or do we want something more fancy like suggestion from #66 (comment)

[jacobheun]

+1 for partial

[achingbrain]

Do we need a match parameter at all? Can we not just look at the passed name and if it contains a * character it's a wildcard match and if not it's exact? Case sensitive/insensitive or search flags could be an option?

[lidel]

@achingbrain
If we replace match with support for * and add optional case=sensitive|insensitive, then services need to implement parser and 4 strategies instead of two (exact-casesensitive, exact-caseinsensitive, partial-casesensitive, partial-caseinsensitive), and API users need to learn that * has special meaning, and we need to spec that it can't be used in names (or spec how to escape it).

I'd argue match=exact|iexact|partial|ipartial added in f96383a is much easier for services and users,
but I'm open for suggestions if there is a simpler way to represent this (when match is missing, exact is used).

[andrew]

PR for implementation on the ruby pinning api server over here: ipfs-shipyard/rb-pinning-service-api#5

[obo20]

This PR looks great to me. The changes will be helpful in keeping things performant by default while also allowing for some flexibility.