MARC Batch Import/Export Queue - Copy Queue To Bucket Doesn't Work as Expected

EG 3.9.4 and EG 3.10.3

Confirming Jennifer's findings.

I did find that if I created a new bucket through the Copy Queue to Bucket action, I was able to copy additional queues to that bucket. In other words, copying a queue to an existing bucket works, but only for buckets created through the Copy Queue to Bucket action.

Confirming still occurs in 3.14-beta

The shared add-to-bucket component does a couple things at load time that stop you from being able to toss vandelay queue records into arbitrary bib containers.

First, it decides the bucket type it is willing to deal with at run time by looking at it's input parameters. If it was handed a queue id via the fromBibQueue input, it sets the bucket type to 'vandelay_queue'. The bucket type is used to look up the list of containers it considers valid targets in "add to existing" mode.

Second, it looks up the users containers of the appropriate class (bib, here) AND TYPE ('vandelay_queue' in the add-from-queue interface), and stores the list of buckets as the authoritative list of valid pre-existing buckets to which it will be willing to add bibs. This list will NEVER (given the current code) include shared buckets, because they are not owned by the active user and that is what it looks up. If you give it a bucket id for a bucket that is not in this list, it simply ignores the id.

So, if the user has no pre-existing 'vandelay_queue'-type bib buckets, the "existing buckets" dropdown will be empty. And, only the buckets that show up in that dropdown are considered valid add targets.

You can, of course, add the records to a BRAND NEW 'vandelay_queue'-type bucket, and then that bucket will be available to you in future instances of this interface.

Other interfaces that do not use the fromBibQueue input for the component use the 'staff_client' (generic) bucket type. In those other interfaces, you will see the list of buckets that the user owns and that have that generic type. In those other interfaces, the user is still restricted to the 'staff_client'-type buckets owned by the user, but you're more likely to see generic buckets, as those are created in many ways, unlike those from the Inspect Queue interface.

With all of that in mind, what do we want the actual behavior to be, both in this interface, and in other non-Vandelay interfaces? Some (but definitely not all) options:
 * Do we want to mix all bucket types in all interfaces? -- This will mix buckets of various purposes together, and seems like a bad idea. You'll be seeing your carousels and URL verification queues and Template-based Batch Update buckets in ALL the interfaces that use this component.
 * Do we want to remove the "you need to own it, and it needs to be the right type" check, and just accept whatever bucket id a staff user types? -- This seems at least error-prone and at most actively dangerous, as you'll be able to throw vandelay queue records into any bucket with any purpose.
 * Do we just need to document this so staff understand that 'vandelay_queue'-type buckets are separate, via type, from other buckets?

NOTE: there are nine (9) stock bib record bucket types, and the list is not locked down -- you can add more to your Evergreen instance for your own purposes.