Tests and fixes for oplog corruption bug

[vigoo]

If a set of conditions were met:

• All entries of the oplog were moved to archive layers from the primary oplog
• All in-memory oplog related instances for the given worker were already dropped from all caches
• The worker is reopened by some new invocation or update request

It could happen that the newly opened oplog used a wrong view of what the "last oplog index" is (only looking at the primary layer), and then the next written entry gets the wrong identifier (1). As this (and many following) index is already used and is stored in one of the archive layers, this becomes a corrupt oplog leading to many unexpected issues.

This pull request:

• Provides a test that reproduced the issue and proves the fix
• Fixes the root cause
• Reduces the effect of trying to open such a corrupt oplog, to not panic but act as if the worker was failed.

(Also updates wasm-rpc to 1.0.3 as it contains some important stub generator fixes.)

[noise64]

can getting the last oplog and open be in a race-condition?

[vigoo]

can getting the last oplog and open be in a race-condition?

only in split-brain scenarios (if another executor is writing the oplog)

normally there is only a single instance of Oplog per worker and that's the only way to append the oplog