Swartzn/add priority and wait queue

[swartzn]

What does this PR do / why do we need it?

• Add priority option to ctl push/pull commands with five priority levels.
• Add IsWorkRequestReady() method to the rst.Provider interface to validate work is ready.
  • Before processing a work request, IsWorkRequestReady() is called to check if the client is prepared to handle it. Clients can use this hook to verify resource availability or other preconditions. If not ready, the request is deferred into the wait queue for the duration returned by IsWorkRequestReady().
• Unit tests have been added to verify the database scheme
• The following code was injected into the s3 provider to test the wait queue,

func (r *S3Client) IsWorkRequestReady(ctx context.Context, request *flex.WorkRequest) (bool, time.Time, error) {
	// Only for testing
	_, err := r.mountPoint.Stat(request.JobId)
	if err != nil && errors.Is(err, fs.ErrNotExist) {
		r.mountPoint.CreateWriteClose(request.JobId, []byte{}, 0600, false)
		retryTime := time.Now().Add(5 * time.Second)
		return false, retryTime, nil
	}
	return true, time.Time{}, nil
}

Note: In order to accommodate the addition of priorities the following protobuf branch is needed: swartzn/add-priority-wait-queue

Where should the reviewer(s) start reviewing this?

There are two commits.

1. Extends mapStore functionality to support getting entries across ranges and exposes GenerateNextPK() so consumers can utilize the counter.
2. Adds a second database for the wait queue and priority schema for the 13-character base-36 submission id key.

The changes to mapStore are independent in the first commit and should be reviewed first . Afterwards, understand the scheme in rst/sync/internal/workmgr/utils.go:L184 before proceeding to the workmgr changes rst/sync/internal/workmgr/manager.go

Checklist before merging:

When creating a PR these are items to keep in mind that cannot be checked by GitHub actions:

• Documentation:
  • Does developer documentation (code comments, readme, etc.) need to be added or updated?
  • Does the user documentation need to be expanded or updated for this change?
• Testing:
  • Does this functionality require changing or adding new unit tests?
  • Does this functionality require changing or adding new integration tests?
• Git Hygiene:
  • Do commits adhere to Conventional Commits?
  • Is the commit history squashed down reasonably?

For more details refer to the Go coding standards and the pull request process.

[swartzn]

@iamjoemccormick I wasn't able to find any reason seq had to be an int64. This way when a key wraps it'll go back to zero instead of negative.

[swartzn]

Parsing the submission id as base-10 resulted in nextExpectedSubmissionID being set to the beginning each time.

[swartzn]

@swartzn Squash commits before merging