Davenverse components into std

[ChristopherDavenport]

trafficstars

For Consideration

• [x] unique
• [x] random
• [ ] FUUID -> UUID (what to do about literal macros)
• [ ] cats-effect-time - java-time instances. Considerations are scala-js artifact size. Perhaps jvm only?
• [ ] mapref - Reference Optimized Around Maps
• [ ] circuit - This went through the rounds once and ended up not incorporated, putting it back for consideration.
• [ ] keysemaphore - Exactly what it sounds like, doesn't space leak as it removes on reaching the set cap for that value
• [ ] agitation - Cooperative Cancellation (this doesn't see a lot of use, but is really useful when you need it)

Unique, and Random have open PR's #1477 and #1478 , all are open for debate.

Just want to make an effort to make sure tools are in locations that they are most useful to the community.

[rossabaker]

A few principles:

• Favor inclusion it if it's small enough to be a "solved problem" and unlikely to evolve until CE4 or have interesting alternatives. Example: unique

• If multiple implementations exist, can we reconcile them before inclusion? If not, maybe the design space is still unsettled. Example: circuit, which also exists in Monix.

• Are the more complex ones used in major libraries or production applications? If the API is still provisional, maybe it waits until CE 3.1. Example: ???

As noted in the CE2 debates as things graduated from FS2 and Monix, it's always easier to add than subtract. Also, we can reduce bus factor on those still maturing by shifting to Typelevel projects or adding maintainers to the Davenverse. I hope some of these make it now, but if in doubt, leave them out.

[RaasAhsan]

It's worth considering #1459 under those principles as well

[RaasAhsan]

If multiple implementations exist, can we reconcile them before inclusion? If not, maybe the design space is still unsettled. Example: circuit, which also exists in Monix.

It's also worth recognizing that even if multiple implementations don't happen to exist, the design space may still be apt for innovation. Retries comes to mind; afaik cats-retry is the only Cats library for them, but I've seen wildly different APIs that work just as well if not better

FWIW, I and likely others see/will see the std module as the de facto way of doing things, so I second a diligent and conservative approach to choosing what to include here

[kubukoz]

Are we considering getting a Logger algebra in there as well? It would be a big win to have it as a "primitive" that other libraries will implement instances for - e.g. @gvolpe's redis4cats has a minimal interface with an interop module for log4cats. Something like that would be a nice addition to std, IMO.

We're looking at logging abstractions for scalacache 1.0.0 and the most likely scenario seems to be going with redis4cats's approach (if it's not going to be pulled in here).