#### Does this PR need a docs update or release note?
- [x] ⛔ No
#### Type of change
- [x] 🐛 Bugfix
- [x] 🤖 Supportability/Tests
#### Test Plan
- [x] 💚 E2E
<!-- PR description-->
Introducing a new `Configurer` interface to abstract out storage config information(for s3, filesystem etc) from caller code. I consider this as a short term solution. We need to consolidate overall config handling in a better way, but that's out of scope for this PR chain.
Testing
* Most of the changes here are code movement under the hood. So relying on existing tests.
* I'll address any test gaps in a later PR.
---
#### Does this PR need a docs update or release note?
- [ ] ✅ Yes, it's included
- [ ] 🕐 Yes, but in a later PR
- [x] ⛔ No
#### Type of change
<!--- Please check the type of change your PR introduces: --->
- [ ] 🌻 Feature
- [ ] 🐛 Bugfix
- [ ] 🗺️ Documentation
- [ ] 🤖 Supportability/Tests
- [ ] 💻 CI/Deployment
- [x] 🧹 Tech Debt/Cleanup
#### Issue(s)
<!-- Can reference multiple issues. Use one of the following "magic words" - "closes, fixes" to auto-close the Github issue. -->
* https://github.com/alcionai/corso/issues/1416
#### Test Plan
<!-- How will this be tested prior to merging.-->
- [x] 💪 Manual
- [x] ⚡ Unit test
- [ ] 💚 E2E
<!-- PR description-->
One of the 2 remaining setup PRs before we can introduce local storage repos.
**Changes:**
1. Read storage provider(`provider`) from config file except for `repo init * ` or `repo connect *` commands.
2. Apply flag overrides based on provider type( e.g. `S3FlagOverrides` if provider is `S3`)
3. Propagate storage provider type to functions which read/write config. These functions arbitrate on config hierarchy - flags, env, config file, in that order.
**Reasons**
* Reason 1 is needed is because config file is the source of truth for storage provider for all commands except `repo init` or `repo connect`. In the exception cases, we pick the provider in command (e.g. `s3`) as the source of truth. e.g. consider a `repo init s3`, followed by `repo init filesystem`.During `repo init filesystem`, config file would indicate `S3` provider, but the correct behavior here is to select `filesystem` provider.
* One alternative was to push provider from the init/connect cmds into an override flag, and let the config code decide on hierarchy. However, this felt hacky. provider here is not a flag to begin with. It's part of init/connect commands.
---
#### Does this PR need a docs update or release note?
- [ ] ✅ Yes, it's included
- [x] 🕐 Yes, but in a later PR
- [ ] ⛔ No
#### Type of change
<!--- Please check the type of change your PR introduces: --->
- [ ] 🌻 Feature
- [ ] 🐛 Bugfix
- [ ] 🗺️ Documentation
- [ ] 🤖 Supportability/Tests
- [ ] 💻 CI/Deployment
- [x] 🧹 Tech Debt/Cleanup
#### Issue(s)
<!-- Can reference multiple issues. Use one of the following "magic words" - "closes, fixes" to auto-close the Github issue. -->
* https://github.com/alcionai/corso/issues/1416
#### Test Plan
<!-- How will this be tested prior to merging.-->
- [x] 💪 Manual
- [ ] ⚡ Unit test
- [ ] 💚 E2E
<!-- PR description-->
* Rename some flags to bring parity with corso cli flags. `--bucket-prefix` to `--prefix`, `--prefix` to `--object-prefix`. This is so that we can avoid passing overrides until sometime later.
* Ideally this change should not be needed. This is part of a stopgap solution to remove s3 coupling from corso cli package.
* A more architectural solution is [managing overrides using viper](https://github.com/alcionai/corso/issues/4219). That change is a bit more involved, so i'll be adding that later.
---
#### Does this PR need a docs update or release note?
- [ ] ✅ Yes, it's included
- [ ] 🕐 Yes, but in a later PR
- [x] ⛔ No
#### Type of change
<!--- Please check the type of change your PR introduces: --->
- [ ] 🌻 Feature
- [ ] 🐛 Bugfix
- [ ] 🗺️ Documentation
- [ ] 🤖 Supportability/Tests
- [ ] 💻 CI/Deployment
- [x] 🧹 Tech Debt/Cleanup
#### Issue(s)
<!-- Can reference multiple issues. Use one of the following "magic words" - "closes, fixes" to auto-close the Github issue. -->
* #<issue>
#### Test Plan
<!-- How will this be tested prior to merging.-->
- [x] 💪 Manual
- [ ] ⚡ Unit test
- [ ] 💚 E2E
Create a CLI utility that checks retention config
information for a small set of objects. Utility
works as follows:
* given a set of prefixes find one current version
of each object
* for each object selected above, retrieve the
retention config
* compare retention mode and expiry with the given
mode and an expiry calculated from the current
time
To attempt to reduce costs, the utility uses the
list API to fetch object names/versions and match
prefixes. It will cancel listing objects (i.e.
stop fetching new pages) once all prefixes are
matched
Also includes a flag to select non-current versions
of objects with the same prefix. However, setting
this flag may lead to more API calls because some
objects may not have non-current versions. In that
case all objects will be listed
sample usage to check current and non-current versions
of an object with prefix 'x' and current and
non-current versions of an object with prefix 'q'.
The current versions should expire in >= 8h and the
non-current versions should expire <= 7h
```
s3checker --bucket <> --bucket-prefix <> \
--prefix x --prefix q \
--retention-mode GOVERNANCE --live-retention-duration 8h \
--with-non-current --dead-retention-duration 7h
```
---
#### Does this PR need a docs update or release note?
- [ ] ✅ Yes, it's included
- [ ] 🕐 Yes, but in a later PR
- [x] ⛔ No
#### Type of change
- [ ] 🌻 Feature
- [ ] 🐛 Bugfix
- [ ] 🗺️ Documentation
- [x] 🤖 Supportability/Tests
- [x] 💻 CI/Deployment
- [ ] 🧹 Tech Debt/Cleanup
#### Issue(s)
* #3799
#### Test Plan
- [x] 💪 Manual
- [ ] ⚡ Unit test
- [ ] 💚 E2E
