[db] move panic handling from goroutine to the parent function

[VihasMakwana]

What does this PR do?

Previously, we listened on ech inside a goroutine and triggered a panic if an error was received. Since the panic occurred within the goroutine, it cannot be recovered by the parent function by design.

This PR changes the flow as follows:

1. Call recursivelyCheckBucket in a goroutine
2. Wait for any errors in the parent function and panic, if any error was received.

This way, the panic happens outside the goroutine and can be recovered.

Testing

Tested following program with a corrupted DB file and recover() works as expected

package main

import (
	"fmt"

	"go.etcd.io/bbolt"
)

func main() {
	defer func() {
		if r := recover(); r != nil {
			fmt.Println("Recovered from:", r)
		}
	}()

	db, _ := bbolt.Open("PATH_TO_DB", 0666, bbolt.DefaultOptions)
	defer db.Close()
}

receiver_filelog_.tgz

Issues

Closes #1011

[rdner]

LGTM if we're going to keep the panic behavior.

But is it even necessary to panic here at all?

Why can't we handle it as an error and propagate it to the consumer letting them to decide what to do with it? Panic seems to be overkill from my point of view.

[ahrtr]

/ok-to-test

[ahrtr]

Please also add a changelog item in this PR under https://github.com/etcd-io/bbolt/blob/main/CHANGELOG/CHANGELOG-1.5.md

[VihasMakwana]

@ahrtr Done! 😄

[ahrtr]

can you please squash/merge the first two commits?

[VihasMakwana]

@ahrtr Done!

[ahrtr]

Thank you!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahrtr, rdner, VihasMakwana

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [ahrtr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment