Improve resource management for block repository backends

[ronoaldo]

It may be needed to allow for callers to manage resources when using the map data from the block repository. I see two opportunities for improvement/fixes:

1/ Implement defer Rows.Close() and DB.Close() on all backends: this may solve memory usage issues as reported here minetest-go/mapcleaner#179 as well as resolve final transactions/connections not being properly released (potentially what is happening here: minetest-go/mapcleaner#180.

2/ Implement a new version of Iterator(), IteratorTo() which receives a block bounding box. It could make concurrency easier to implement like for exporting all protected areas in separate go-routines. Also, perhaps a single iterator that keeps sql.Rows always open and only closes at the end could be a bad idea. If there are just too many blocks in the map (the main use case for cleaning the map) it can use just too much memory.

Open for feedback/thoughts on this!

---

Checklist:

• Implement BlockRepository.Close().
• Ensure sql.Rows.Close() is called.
• Batch Iterator() to avoid single sql.Rows open for too much time.
• Implement IteratorTo()  #79

[BuckarooBanzay]

(reopening, looks like there are still 2 tasks open)

[ronoaldo]

(reopening, looks like there are still 2 tasks open)

yeah! thanks! I'm going to test how Iterator() performs on a 80G/150M blocks map cleanup task and if it indeed causes resource usage issues due to a single reference to sql.Rows I'll batch them.

I have split the IteratorTo() as a new task. It is kind of a very similar impl. but may benefit from the perf. improvement if any.

[ronoaldo]

#80 should resolve this.
Should also help with minetest-go/mapcleaner#185 because it uses a pure-go SQLite implementation.