(feat): Refactor Resize Capabilities

[lasith-kg]

This PR will create a v2. I am decommissioning resizeThreshold, renaming resizeFs to resize and converting the data type of lvmConsumption from int to uint64

FAQ

• Why am I removing resizeThreshold?
  • While developing the resize capabilities for lvm2, I realised that hard-coding a sensible threshold amount was more scalable than creating a configurable threshold for each resize category
  • Imagine the chaos of having lvResizeThreshold, vgResizeThreshold and resizeThreshold!
  • In this PR, I set resizeThreshold to a default value of 99.999% Explanation
• Why am I renaming resizeFs to resize?
  • We are now consuming resizeFs to determine whether a Physical Volume and Logical Volume needs to be resized.
  • These resources are not filesystems. I cannot write to a Logical Volume or Physical Volume as if it was an xfs file system
  • By renaming resizeFs to resize, I keep it concise and relevant to how it is being used throughout the application
• Why did I change lvmConsumption from int to uint64?
  • lvmConsumption represents a percent value between 0 and 100
  • This will always be a positive value so lets ensure that the data type reflects this constraint
  • I cannot use uint16 or uint32 because they are not supported by the flags library
• Why did I move the tolerances and threshold values from the layer to backend package?
  • During lvm development, I was reminded that the purpose of the layer was to act as the orchestrator
  • These threshold and tolerance values should be abstracted away from the layer
  • It is simpler to have the layer invoke a function like backend.ShouldResize(device) rather than backend.ShouldResize(device, threshold)
• Why are we going up a major version?
  • Renaming an attribute: resizeFs to resize
  • Removing an attribute: resizeThreshold
  • Recent edition of LVM support to ebs-bootstrap