fix: attach volume on #save, remove #server=

[lanej]

s/service/server/ in Volume#save. Fixes attaching after initialization.

Require users to call Volume#attach(server, device) to attach a volume after it's created. Volume#server=(new_server) having a side-effect of attaching a volume is confusing.

Volume#device set on Volume#initialize will be lost when calling Volume#wait_for in fog-core ~> 2.0.

BREAKING CHANGE

Volume#server= is removed.

[lanej]

 FOG_MOCK=false bundle exec shindo tests/models/compute/volume_tests.rb
[fog][WARNING] Setting default fog timeout to 2000 seconds

  Fog::Compute[:aws] | volume (aws)
    success
      #save + succeeds
      attached + succeeds
      #detach + succeeds
      #attach(server, device) + succeeds
      #force_detach + succeeds
+ returns true
+ returns "io1"
+ returns 5000
+ returns 100
      @instance.tags + returns {"key"=>"value"}
      #destroy + succeeds

  11 succeeded in 385.32015 seconds

Coverage report generated for Shindo to /Users/jlane/p/fog-aws/coverage. 2849 / 6718 LOC (42.41%) covered.

[geemus]

Looks good, as per previous discussion.

The only question I would still have is, is there a reasonable way for us to warn people more directly if they are expecting the old usage? I'm not sure, but if we can warn that would be good, so I welcome your thoughts.

[lanej]

The old usage would require someone to use Volume#server= which will get them a NoMethodError (as of this change).

This is certainly a major bump. Not sure what Fog considers best practices in this case.

[geemus]

Maybe we could define a Volume#server= in order to have it raise a more explanatory error message? We haven't really had this situation enough to have a policy per se. Usually I've tried to just deprecate and then eventually drop, rather than just dropping functionality. But that doesn't seem very doable here.

[lanej]

Deprecation is not an option in this case.

I will add Volume#server= back in with a message leading the user to Volume#attach

[geemus]

@lanej yeah, I was pretty sure deprecation wasn't possible unless I was totally missing something. I think the more explicit error message sounds like a great just-in-case. Thanks!

[geemus]

Thanks for the extra care/messaging. LGTM.