make sure that deleteFeed is idempotent and performant

[staltz]

Context: I have an idea for deleting blocked feeds in an automatic way: use ssb-friends to scan all the blocked feeds and call deleteFeed on them. In case those feeds were already deleted, we need to make sure that deleteFeed is going to be performant and not cause any bugs.

Solution: when clearing the base index, this PR now checks first if an entry exists for that feedId. If it exists, then we can avoid calling flush and level.del in vain.

An important thing to keep in mind is that deleteFeed is not atomic. The app may crash in the middle of a deleteFeed, meaning that some messages owned by that feed are deleted, but not all of them. So in a sense it's desired to call deleteFeed every time the app is opened, to make sure all messages are deleted.

Check more comments I put in the implementation of deleteFeed just to explain my points better:

self.query(
  where(author(feedId)),
  asOffsets(),
  toCallback((err, offsets) => {
    if (err) return cb(clarify(err, 'deleteFeed() failed to query jitdb'))
    //
    // if `offsets` is empty, then the push-stream pipe below 
    // skips directly to the collect
    //
    push(
      push.values(offsets),
      push.asyncMap(log.del),
      push.collect((err) => {
        if (err) cb(clarify(err, 'deleteFeed() failed for feed ' + feedId))
        else {
          //
          // this `delete` should be fast
          //
          delete state[feedId]
          //
          // this removeFeedFromLatest should be fast
          //
          indexes.base.removeFeedFromLatest(feedId, cb)
        }
      })
    )
  })
)

[staltz]

These changes are unrelated to the PR, but when I ran prettier, the decode ended up taking many lines, so I refactored to create the pValueAuthor and keep each of these a one-liner.

[staltz]

Mysterious, why isn't the CI completing within 10minutes...

Whaaat, the npm install is taking more than 10minutes and getting stuck..

[arj03]

Maybe CI acting up. Node 16 ran fine.

[arj03]

Looks good

[staltz]

I investigated this locally by running npm install --verbose with node.js 14 and 16, and it really just takes a long long time to install. I don't know why, but it seems like when it reaches ssb-bfe-spec and ssb-bfe (and other repos, but not all, repos that we moved from ssb-ngi-pointer to ssbc), it gets stuck on those particular repos for a long while. I don't understand why the GitHub transferring would have an effect, because npm packages are not on GitHub at all. Maybe we can just blame this on npm.com itself and move on. It might affect all kinds of PRs, and would be good to improve the install duration eventually.

[staltz]

Tests pass locally with node.js 12 and 14 and 16 so I'll merge.