Logger improvements (#7729)

* Remove enablement

* Refactor context and filtering

* Fix imports, simplify transports config

* Migrate usages of debug context

* Re-org, add colors and grouping to console logging

* Remove temp default context

* Remove manual prefix

* Move colorizing out of console transport body

* Reduce reuse

* Pass through context

* Ensure bitdrift is enabled in dev

* Enable Sentry on web only

* Clean up types

* Docs

* Format

* Update tests

* Clean up tests

* No positional args

* Revert Sentry changes

* Clean up context, use it, pass metadata through to Bitdrift

* Fix up debugging

* Clean up metadata before passing to Bitdrift

* Correct transports

* Reserve context prop on metadata and include in transports

* Update tests

1 files changed, 24 insertions, 78 deletions

diff --git a/src/logger/README.md b/src/logger/README.md
index 8da7deb14..e3476efdf 100644
--- a/src/logger/README.md
+++ b/src/logger/README.md
@@ -1,99 +1,45 @@
 # Logger
 
-Simple logger for Bluesky. Supports log levels, debug contexts, and separate
-transports for production, dev, and test mode.
+Simple logger for Bluesky.
 
 ## At a Glance
 
 ```typescript
-import { logger } from '#/logger'
+import { logger, Logger } from '#/logger'
 
-logger.debug(message[, metadata, debugContext])
-logger.info(message[, metadata])
-logger.log(message[, metadata])
-logger.warn(message[, metadata])
-logger.error(error[, metadata])
-```
-
-#### Modes
+// or, optionally create new instance with custom context
+// const logger = Logger.create(Logger.Context.Notifications)
 
-The "modes" referred to here are inferred from `process.env.NODE_ENV`,
-which matches how React Native sets the `__DEV__` global.
-
-#### Log Levels
+// for dev-only logs
+logger.debug(message, {})
 
-Log levels are used to filter which logs are either printed to the console
-and/or sent to Sentry and other reporting services. To configure, set the
-`EXPO_PUBLIC_LOG_LEVEL` environment variable in `.env` to one of `debug`,
-`info`, `log`, `warn`, or `error`.
+// for production breadcrumbs
+logger.info(message, {})
 
-This variable should be `info` in production, and `debug` in dev. If it gets too
-noisy in dev, simply set it to a higher level, such as `warn`.
+// seldom used, prefer `info`
+logger.log(message, {})
 
-## Usage
-
-```typescript
-import { logger } from '#/logger';
-```
+// for non-error issues to look into, seldom used, prefer `error`
+logger.warn(message, {})
 
-### `logger.error`
+// for known errors without an exception, use a string
+logger.error(`known error`, {})
 
-The `error` level is for... well, errors. These are sent to Sentry in production mode.
-
-`error`, along with all log levels, supports an additional parameter, `metadata: Record<string, unknown>`. Use this to provide values to the [Sentry
-breadcrumb](https://docs.sentry.io/platforms/react-native/enriching-events/breadcrumbs/#manual-breadcrumbs).
-
-```typescript
+// for unknown exceptions
 try {
-  // some async code
 } catch (e) {
-  logger.error(e, { ...metadata });
+  logger.error(e, {message: `explain error`}])
 }
 ```
 
-### `logger.warn`
-
-Warnings will be sent to Sentry as a separate Issue with level `warning`, as
-well as as breadcrumbs, with a severity level of `warning`
-
-### `logger.log`
-
-Logs with level `log` will be sent to Sentry as a separate Issue with level `log`, as
-well as as breadcrumbs, with a severity level of `default`.
-
-### `logger.info`
-
-The `info` level should be used for information that would be helpful in a
-tracing context, like Sentry. In production mode, `info` logs are sent
-to Sentry as breadcrumbs, which decorate log levels above `info` such as `log`,
-`warn`, and `error`.
-
-### `logger.debug`
-
-Debug level is really only intended for local development. Use this instead of
-`console.log`.
-
-```typescript
-logger.debug(message, { ...metadata });
-```
-
-Inspired by [debug](https://www.npmjs.com/package/debug), when writing debug
-logs, you can optionally pass a _context_, which can be then filtered when in
-debug mode.
-
-This value should be related to the feature, component, or screen
-the code is running within, and **it should be defined in `#/logger/debugContext`**.
-This way we know if a relevant context already exists, and we can trace all
-active contexts in use in our app. This const enum is conveniently available on
-the `logger` at `logger.DebugContext`.
+#### Log Levels
 
-For example, a debug log like this:
+Log level defaults to `info`. You can set this via the `EXPO_PUBLIC_LOG_LEVEL`
+env var in `.env.local`.
 
-```typescript
-logger.debug(message, {}, logger.DebugContext.composer);
-```
+#### Filtering debugs by context
 
-Would be logged to the console in dev mode if `EXPO_PUBLIC_LOG_LEVEL=debug`, _or_ if you
-pass a separate environment variable `LOG_DEBUG=composer`. This variable supports
-multiple contexts using commas like `LOG_DEBUG=composer,profile`, and _automatically
-sets the log level to `debug`, regardless of `EXPO_PUBLIC_LOG_LEVEL`._
+Debug logs are dev-only, and not enabled by default. Once enabled, they can get
+noisy. So you can filter them by setting the `EXPO_PUBLIC_LOG_DEBUG` env var
+e.g. `EXPO_PUBLIC_LOG_DEBUG=notifications`. These values can be comma-separated
+and include wildcards.