Fix(scheduler): use SpaceWeighted as the default scheduler

[nkwangleiGIT]

Pull Request template

Please, go through these steps before you submit a PR.

Why is this PR required? What issue does it fix?: Fix issue https://github.com/openebs/lvm-localpv/issues/188

What this PR does?: Use SpaceWeighted as the default scheduler

Does this PR require any upgrade changes?: No

If the changes in this PR are manually verified, list down the scenarios covered:: 1、Install openebs lvm 2、Create lvm storageclass（Use two K8S nodes for lvm provision) 3、Create PVC to use the sc above to provision LVM volume, to make sure it use the SpaceWeighted when schedule LVM volume

Any additional information for your reviewer? : Mention if this PR is part of any design or a continuation of previous PRs

Checklist:

• [ ] Fixes #
• [ ] PR Title follows the convention of <type>(<scope>): <subject>
• [ ] Has the change log section been updated?
• [ ] Commit has unit tests
• [ ] Commit has integration tests
• [ ] (Optional) Are upgrade changes included in this PR? If not, mention the issue/PR to track:
• [ ] (Optional) If documentation changes are required, which issue on https://github.com/openebs/openebs-docs is used to track them:

PLEASE REMOVE BELOW INFORMATION BEFORE SUBMITTING

The PR title message must follow convention: <type>(<scope>): <subject>.

Where:

• type is defining if release will be triggering after merging submitted changes, details in CONTRIBUTING.md. Most common types are:

  • feat - for new features, not a new feature for build script
  • fix - for bug fixes or improvements, not a fix for build script
  • chore - changes not related to production code
  • docs - changes related to documentation
  • style - formatting, missing semi colons, linting fix etc; no significant production code changes
  • test - adding missing tests, refactoring tests; no production code change
  • refactor - refactoring production code, eg. renaming a variable or function name, there should not be any significant production code changes

• scope is a single word that best describes where the changes fit. Most common scopes are like:

  • data engine (localpv, jiva, cstor)
  • feature (provisioning, backup, restore, exporter)
  • code component (api, webhook, cast, upgrade)
  • test (tests, bdd)
  • chores (version, build, log, travis)

• subject is a single line brief description of the changes made in the pull request.

[pawanpraka1]

@nkwangleiGIT can you DCO signoff this PR?

[nkwangleiGIT]

Signed-off-by: nkwangleiGIT nkwanglei@126.com done

[pawanpraka1]

@nkwangleiGIT Would you like to mention your use case in our adopters(https://github.com/openebs/openebs/issues/2719) file.

[nkwangleiGIT]

@pawanpraka1 sure, I just need to add our user case here https://github.com/openebs/openebs/issues/2719?

[pawanpraka1]

@nkwangleiGIT that is right. You can put a comment describing your use case.

[nkwangleiGIT]

sure, done