Inbox retry policy

        `Context` (was `RequestContext`).

     -  The type of `InboxErrorHandler` callback type's first parameter became

        `Context` (was `RequestContext`).

     -  The type of `SharedInboxKeyDispatcher` callback type's first parameter

        became `Context` (was `RequestContext`).

 -  Implemented fully customizable retry policy for failed tasks in the task

    queue.  By default, the task queue retries the failed tasks with

    an exponential backoff policy with decorrelated jitter.

     -  Added `outboxRetryPolicy` option to `CreateFederationOptions` interface.

     -  Added `inboxRetryPolicy` option to `CreateFederationOptions` interface.

        [[#70]]

     -  Added `RetryPolicy` callback type.

     -  Added `RetryContext` interface.

     -  Added `createExponentialBackoffPolicy()` function.

the `createExponentialBackoffRetryPolicy()` function, which is a default

implementation of the retry policy.

### `inboxRetryPolicy`

*This API is available since Fedify 0.12.0.*

The retry policy for processing incoming activities.

By default, this uses an exponential backoff strategy with a maximum of 10

attempts and a maximum delay of 12 hours.

In the same way as the `outboxRetryPolicy` option, you can fully customize

the retry policy by providing a custom function that satisfies the `RetryPolicy`

type.  Or you can adjust the parameters of the built-in 

`createExponentialBackoffRetryPolicy()` function.

How the `Federation` object recognizes the domain name

------------------------------------------------------

Usually, processes inside an inbox listener should be non-blocking because

they may involve long-running tasks.  Fortunately, you can easily turn inbox

listeners into non-blocking by providing a [`queue`](./federation.md#queue)

option to `createFederation()` function.  If it is not present, incoming

activities are processed immediately and block the response to the sender until

the processing is done.

option to `createFederation()` function:

While the [`queue`](./federation.md#queue) option is not mandatory,

it is highly recommended to use it in production environments to prevent

the server from being overwhelmed by incoming activities.

~~~~ typescript

import { createFederation, InProcessMessageQueue } from "@fedify/fedify";

const federation = createFederation({

  // Omitted for brevity; see the related section for details.

  queue: new InProcessMessageQueue(),  // [!code highlight]

});

~~~~

> [!NOTE]

> The `InProcessMessageQueue` is a simple in-memory message queue that is

> suitable for development and testing.  For production use, you should

> consider using a more robust message queue, such as `DenoKvMessageQueue`

> from `@fedify/fedify/x/deno` module or [`RedisMessageQueue`] from

> [`@fedify/redis`] package.

If it is not present, incoming activities are processed immediately and block

the response to the sender until the processing is done.

While the `queue` option is not mandatory, it is highly recommended to use it

in production environments to prevent the server from being overwhelmed by

incoming activities.

With the `queue` enabled, the failed activities are automatically retried

after a certain period of time.  The default retry strategy is exponential

backoff with a maximum of 10 retries, but you can customize it by providing

an [`inboxRetryPolicy`](./federation.md#inboxretrypolicy) option to

the `createFederation()` function.

> [!NOTE]

> Activities with invalid signatures/proofs are silently ignored and not queued.

[`RedisMessageQueue`]: https://jsr.io/@fedify/redis/doc/mq/~/RedisMessageQueue

[`@fedify/redis`]: https://github.com/dahlia/fedify-redis

Error handling

--------------

an outgoing activity to the queue instead of immediately sending it to

the recipient's inbox if possible; the system retries the delivery on failure.

This queueing mechanism is enabled only if `Federation` object has a `queue`:

This queueing mechanism is enabled only if a [`queue`](./federation.md#queue)

option is set to the `createFederation()` function:

~~~~ typescript

import { createFederation, InProcessMessageQueue } from "@fedify/fedify";

> [!NOTE]

> The `InProcessMessageQueue` is a simple in-memory message queue that is

> suitable for development and testing.  For production use, you should

> consider using a more robust message queue, such as `DenoKvMessageQueue`.

> consider using a more robust message queue, such as `DenoKvMessageQueue`

> from `@fedify/fedify/x/deno` module or [`RedisMessageQueue`] from

> [`@fedify/redis`] package.

The failed activities are automatically retried after a certain period of time.

The default retry strategy is exponential backoff with a maximum of 10 retries,

but you can customize it by providing

an [`outboxRetryPolicy`](./federation.md#outboxretrypolicy) option to

the `createFederation()` function.

If the `queue` is not set, the `~Context.sendActivity()` method immediately

sends the activity to the recipient's inbox.  If the delivery fails, it throws

an error and does not retry the delivery.

[`RedisMessageQueue`]: https://jsr.io/@fedify/redis/doc/mq/~/RedisMessageQueue

[`@fedify/redis`]: https://github.com/dahlia/fedify-redis

Immediately sending an activity

-------------------------------

 * of the {@link Context} passed to the shared inbox listener.

 *

 * @typeParam TContextData The context data to pass to the {@link Context}.

 * @param context The request context.

 * @param context The context.

 * @returns The handle of the actor or the key pair for the authenticated

 *          document loader of the {@link Context} passed to the shared inbox

 *          listener.  If `null` is returned, the request is not authorized.

 * @since 0.11.0

 */

export type SharedInboxKeyDispatcher<TContextData> = (

  context: RequestContext<TContextData>,

  context: Context<TContextData>,

) =>

  | SenderKeyPair

  | { handle: string }