The default backoff policy does not have mandatory stop, which could cause unexpected send timeout

#### Expected behavior

For a producer, when the retry time exceeds the left time when a message would fail with timeout error, it should be reduced to be less than the left time.

See `ProducerImpl`'s constructor in Java client:

```java
this.connectionHandler = new ConnectionHandler(this,
new BackoffBuilder()
.setInitialTime(client.getConfiguration().getInitialBackoffIntervalNanos(), TimeUnit.NANOSECONDS)
.setMax(client.getConfiguration().getMaxBackoffIntervalNanos(), TimeUnit.NANOSECONDS)
.setMandatoryStop(Math.max(100, conf.getSendTimeoutMs() - 100), TimeUnit.MILLISECONDS)
.create(),
```

There is a `mandatoryStop` field.

#### Actual behavior

The default backoff policy simply increases the next delay until the max retry time (60s).

#### Steps to reproduce

```go
func TestBackoff_NextMinValue(t *testing.T) {
backoff := &DefaultBackoff{}
for i := 0; i < 10; i++ {
delay := backoff.Next()
fmt.Println(delay)
}
}
```

Modify the test above in `backoff_test.go` and run `go test -run TestBackoff_NextMinValue` in the same directory.

```
111.555037ms
213.388077ms
466.046518ms
940.55396ms
1.614542567s
3.383705308s
6.806575903s
15.159677039s
25.637999048s
1m0.834600978s
```

#### System configuration
**Pulsar version**: x.y

Start with DefaultBackoff and backoff_test.go, then run go test -run TestBackoff_NextMinValue in that directory to observe the current delay sequence. Done means the default retry delay is bounded below the remaining send-timeout window instead of continuing toward the 60-second maximum.

Written by the indexing model from the issue text.