Future Enhancements

We've been using `pobox` for a while now and we have identified a set of issues some of which might need a new major version to resolve. My goal here is to get some feedback.

The first issue: messages have equal weight. That is not suitable for situations where messages have significantly different sizes, affecting the memory footprint of the buffer. This would mean that the PO Box would effectively have two limits a message count limit (total number of messages) and a total buffer weight limit (sum of all message weights). The buffer would store a structure like this {Weight, message}. This can be used also for the filtering function in active state (desired weight vs. desired message count).
A friend suggested that a configurable function to calculate weights would be more flexible. The downside is that calculations done on the `pobox` side may affect performance. Hence we propose an explicitly stored, pre-calculated weight.

The second issue is we want to fail fast when the PO Box is full (suitable for “keep-old” buffers): the client can receive early feedback from the `post_sync` call. This functionality already exists. But there is an issue with latency when sending many consecutive messages from the same client. We’d like to send multiple messages without waiting for a reply each time (avoiding a stop and go type communication). Support for promises similar to `rpc:async_call/4` and `rpc:yield/1` could be used when multiple messages need to be sent concurrently from the same process.
Note that a message can still be discarded at a later stage, even if it didn’t “fail fast”.

The third issue I see is that there isn't a built-in way to use a PO Box with calls: the PO Box owner responds directly to the client when processing the message received from the PO Box. I have emulated this by rolling my own fork of `gen:call` with support for early feedback when the PO Box is full. But I feel this belongs inside the `pobox` library. Here is an illustration of the happy path in this crappy ASCII diagram:

```
+------+ +-----+ +-----+
|client| |pobox| |owner|
+--+---+ +--+--+ +--+--+
| post_call | |
+-> |---------------->| got mail |
| | |---------------->|
| | | send it |
| | |<----------------|
client | | | messages |
blocked | | |---------------->|
| | | ... |
| | | |
| | reply to post_call |
+-> |<----------------------------------|
| | |
```

No source files or tests are named. Start by reading the existing pobox handling around post_sync, then compare the requested asynchronous behavior with rpc:async_call/4, rpc:yield/1, and gen:call; this issue is only complete when the proposed weighting, fail-fast asynchronous posting, and call support have an agreed design and corresponding coverage.

Written by the indexing model from the issue text.