Upgrade to shared_bucket_access with GSI can cause missed mutations

When upgrading/switching over to shared_bucket_access, with views we can just reuse the same ones, whereas for GSI we need a new version to pick up the xattr (e.g. sg_access_1 vs sg_access_x1) - this has the side effect that only migrated documents are available for index-based requests (e.g. changes feed). Provided that there's an import node, this will eventually stabilise once all docs are migrated and become available, and any requests in the meantime may just receive slightly stale data.

There's an issue here though that the migration order is not guaranteed. Take the scenario where there are 1000 active docs with sequences 1..1000: if these are imported in the order 1,2,700,3,4... then any changes feed client connecting at this point will get a response along the lines of:

{

  "results":[

    {"seq":1,"id":"doc_1",...},

    {"seq":2,"id":"doc_2",...},

    {"seq":3,"id":"doc_3",...},

    {"seq":4,"id":"doc_4",...},

    {"seq":700,"id":"doc_700",...}],

  "last_seq": 700

}

If this client then start asking for changes with since=700, it can potentially miss documents that weren't migrated at the time of its first request.

It's possible to workaround this by using views or taking a maintenance window to allow the migration to complete, but both of these options do have downsides.